What motivates organizations to spend time and resources on enabling the enterprise architectural process? Sometimes it's a well-defined problem that needs to be solved. But often it's a vague notion that some set of problems needs to be explained, organized and then solved. That’s where cartography comes in: It explains a set of concepts dealing with notions (logical objects), their behavior and interaction, and the resulting physical objects derived from the notions.

In other words, it's a plan for an architecture, and it's something that shouldn't be lost in the process of actually creating the architecture. Instead, it should be well documented and revisited over time as your problem domain changes.

With cartography, the overall intent is to define a measurable and repeatable process, from requirements to design, but your initial goals are to:

• Reduce complexity through generalization (Note: Avoiding complexity at this stage is fine, but don’t      avoid it during the architecture phase, which comes next. Doing so can come back to bite you later.)
• Separate the logical from the physical
• Eliminate issues that are not relevant to the architecture
• Consistently describe what needs to be architected, and then implemented

As with any form of cartography, the architecture cartography I propose here defines the attributes used, including definitions for:

• Symbology – Standard objects, pictures, or even words that are used to describe something by association;
• Naming – A common approach to naming, including abbreviations, numbering, and compound words;
• Generalization and abstraction – Wikipedia describes abstraction as a process by which higher concepts are derived from usage and classification of literal concepts. In general, it’s a way to represent something complex using a simpler concept (i.e. representing the Internet as a cloud on a whiteboard).

Naming conventions are a matter of personal taste, so I won't attempt to suggest one. However, I will suggest that you be consistent throughout with whatever convention you use. Let's take a closer look at the remaining goals, and how the attributes of the proposed cartography can help you achieve them.

Charting Your Course

To be successful as an architect, you must be able to deal with the abstract and then generalize real and sometimes complex things as simple boxes, lines or dots on a page. It's important to be clear when presenting your architecture and ideas. A standard symbology is often the key here, with an architectural taxonomy, which forms a “road map” to design, if you will.

For instance, aim to create a high-level view of the components in your proposed system (which may be entire systems and subsystems themselves), with clickable items that open new pages. At this point, the relationships between the components should be very simple, such as is a, has a, uses and so on. The diagram below is a simplified example of how this would work:

Taxonomy in the Architecture Cartography. Source: Eric Bruno

I chose Unified Modeling Language (UML) for my symbology, although entity relationship (ER) diagrams, flow charts or other meta-modeling language such as the Object Management Group’s (OMG) Meta-Object Facility work as well. In fact, they may each be used together. Level One systems typically are the enterprise applications that you're architecting, while Level Two systems are the strategic systems or services that your applications use (i.e., authentication, billing and so on). You can have as many levels as your architecture dictates, with the end level being external systems not owned by your enterprise. As a general guideline, components at each level have relationships with components within their own level, or either adjacent level (back one level, or over to the next level).

At this point, while you're dealing with abstract, logical concepts, you're beginning to get a feel for what may become physical entities within your enterprise. For instance, while the billing system uses a single box for its Web service and a cylinder to represent a database, each of these will most likely turn into multiple physical servers with network equipment, security facilities and other administrative systems in the end. Your diagrams should save this level of detail for the architecture documents, which will be developed as part of the architecture process following the cartography stage.   

What Not to Do

In the spirit of eliminating irrelevant issues, you should avoid adding design-specific or implementation-specific items to your cartography, such as load-balancing equipment, platform and OS choices, programming languages, data center distribution and so on. The intent of your cartographic taxonomy is to determine what systems will exist in your architecture, as well as which ones won't (i.e., existing or external systems). When complete, you'll have scoped out the architecture work that needs to be done, where each page in the cartography typically maps to a separate document in your architecture.

Always remember to keep the cartography up to date as you make overarching changes to the architecture. Such changes can be anything from deciding there's a need for an LDAP server (which plays into the authentication system) to the decision to use an external ERP or CRM system instead of deploying your own (such as Salesforce.com). That’s important, because the information within the cartography is a good starting point for those who need an overview and a road map to your business’s enterprise architecture vision. It can also serve as a business guide, quickly communicating the core areas of business on which your enterprise should focus, as opposed to those for which you should find partners.

Let me address the question I’m sure you have, which is about what tools can facilitate your cartography construction. Some tools I’ve used for this include Unified Modeling Language (UML) diagramming tools, such as IBM Rational Rose, Microsoft Visio or OmniGroup’s OmniGraffle, and entity relationship diagramming tools such as CA ERwin. That said, this really is a more personal approach and I know of no all-inclusive package that supports it.  One interesting idea some folks have expressed to me is the possibility of using a tool such as Second Life to create a 3D space to visualize the cartography, and explore it by walking around it. That’s an intriguing idea, but not one that I’ve tackled yet. I’d like to hear other people’s opinions on this approach, so feel free to share if you’d like.

In the meantime, to explore and learn more about meta-modeling, cartography and system taxonomies, see the OMG's website, or information on UML modeling tools, as well as data modeling and entity relationship tools such as CA Technologies’ Erwin.

It’s a good day—one of my favorite TV shows, “Shark Tank,” has its season premiere. For the uninitiated, this is a show where would-be corporate titans angle for a big break, getting the attention of — and investment dollars from — very well-heeled entrepreneurs such as real estate maven Barbara Corcoran, FUBU fashion magnate Daymond John, tech innovator Robert Herjavec, infomercial 'founder' Kevin Harrington, and Kevin O’Leary, who made billions selling his educational software company to The Mattel Toy Co. Starting this season, the Shark Tank entrepreneur lineup also includes media and sports luminary Mark Cuban, who owns the Dallas Mavericks, and Jeff Foxworthy, too. (Yes, that Jeff Foxworthy, the comedian, author and TV personality who seems to have made being a U.S. redneck and competitive grade-school smarts a profitable enterprise.)

I recommend that you put “Shark Tank” on your watch list, if you haven’t already. You probably have — or should have — more in common with its entrepreneurial hopefuls than you know. (If you can’t make 8 p.m. ET Fridays this season there’s always the Internet.) There’s the whole vision thing that you may relate to, of course. So just as Jonathan Miller, in “Shark Tank” episode 6, had a well thought-out, end-to-end plan for a custom energy-bar business, you know you have a plan that can holistically integrate your enterprise as well.

But an enterprise architect should consider himself or herself an entrepreneur in other respects, and maybe that’s where the “Shark Tank” entrepreneurs can lend a hand, if you can judge from past seasons. Let’s take a look at their tactics.

Communicate the Passion, Make the Sale

Season One, Episode 7: Grill Charms. Leslie Haywood exudes confidence that her idea has legs — confidence born from experience, which includes lots of grilling in her native South Carolina, and proven success. Her grill charms — little stainless steel charms you put in meat before you grill it to separate the medium-done from the rare, and such — made her $60,000 in her first year of business. And she knows where she’s heading, too: She sees how her product intersects with not only the grilling industry, but also the gifting and licensing industries (say, for sports teams that want to make some money off those tailgate parties). She’s so good at making her case, three of the Sharks want in.

Here’s your takeaway: Regardless of your background, you’ve got to be able to sell, too. Getting buy-in for enterprise architecture efforts from your business and IT partners means you have to make them want a piece of your vision as much as the Sharks wanted in on Haywood’s. That means laying out passionate proof of what you’ve already delivered and how that supports the business’s mission. Save your passionate discussion of composites for your EA teammates, and coherently show a growth path as to how EA can have a further positive impact on the enterprise. For instance, if you’ve consistently delivered technical architecture wins, play them up — and paint a vivid picture of how much more EA has to contribute to the intersections that matter in your world; namely, between business and IT. 

Take an Inch with the Mile in Mind

Season One, Episode 14: LipStix ReMix. Entrepreneur Jill Quillin has a product that keeps the last bit of lipstick in a tube from going to waste. It’s a hit with the Sharks but, after stepping away to think about the investment options on the table, Quillin returns to learn that there’s been some wheeling and dealing; the investors want a greater share of her business than they did just a few minutes before. Not one to dwell in the trees and miss out on the forest, she takes the offer.

In fact, that was this entrepreneur’s second compromise of the day, and it ultimately meant she gave up 50 percent of her company for the investment rather than the 30 percent she originally offered. But you know what they say: “The perfect is the enemy of the good,” and “Sticking to your guns sometimes backfires.” That’s not a recommendation to be a pushover, but it is advice to be flexible enough that all stakeholders can get behind the big picture EA vision you want to promote — if not its every granular detail — and actually be accountable to living it in practice. 

Pick Yourself Up, Dust Yourself Off

Season One, Episode 1: Mr. Tod’s Pie Factory. Entrepreneur Tod Wilson stumbles by going too big, too fast in his wholesale and retail bakery business, sinking to the point where he had to live in his car. But he pulled himself together, caught the eye of McDonald’s (possible in-store pie kiosks), and, with the Sharks’ 50 percent stake in his company, now has tripled his business.

Sound familiar? Perhaps the part about not having the success you expected when you tried to go big and make a case to the organization that you can, and should, have an impact beyond technical landscapes or local deliveries. Maybe it’s time to follow Mr. Tod’s example and regroup: Reinvest more energy in focused success where IT and business leadership expect it. In other words, accumulate the smaller wins that may someday get the in-house “McDonald’s” team to start thinking bigger about EA, too.

If these examples whet your entrepreneurial appetite, slip on your scuba gear and dive into the Smart Architect tank. And please send up a message in a bottle that describes your own ideas about the enterprise architect’s role as entrepreneur amid the sharks!

Building a cloud strategy can be a challenge, and moving existing applications to the cloud can be downright stressful. You don't want to miss out on the business and technical benefits of doing so, but you also don't want to risk disrupting customers in the process. 

In my previous blog on this topic, I discussed the business criteria around determining what should move out to the cloud. In this installment, let's explore the technical criteria — and rewards — to help determine which parts of your applications should move into the cloud

What Goes Up ... Stays in the Cloud

As an enterprise architect, your biggest motivation should be to solve business problems. But sometimes the reasons for an architecture decision are purely technical. And, in the case of cloud computing, what goes up will not come down, so to speak. When I've helped corporations build a cloud strategy, the main technical drivers for determining what should become a service have been the following:

·         Scalability: Will moving a key component into the cloud help increase scalability? If the answer is yes, this is a good choice. Sometimes, the cloud even presents opportunities to increase scalability that cannot be reached otherwise. For instance, REST-based services, with the low overhead of XML over HTTP compared with other component technologies (such as .Net and CORBA), provide extreme scalability. This scalability can be enhanced by Web-based technology such as highly tuned Web servers and load balancers. Also, individual services can be scaled differently, according to usage patterns. When part of a monolithic application, all of your components must be scaled identically.

·         Elasticity: Building on scalability, on-demand computing applies resources to a cloud-based service based on application demand. Cloud providers often offer provisioning services that automatically scale a service to meet demand, or provide management services to allow you control this according to key parameters – i.e. bandwidth, transaction rates, and so on.

·         Portability: Often, moving legacy systems to the cloud via Web adapters or an enterprise service bus can provide portable, platform-independent access to an otherwise proprietary system. Doing this can help expose a specialized system with a restrictive API, or with single-platform access requirements (i.e., a Windows API or a Unix signal handler) to other applications, regardless of platform or language. If you have a legacy application that's tied to a single platform or technology, consider moving it to the cloud (by building a cloud-based adapter service) for platform-independent reuse. Note here: service enabling an application can be a considerable task, and require a great deal of investment in terms of time and money.

·         Stateless components: If an application contains components where the logic is stateless by nature (i.e., transaction-oriented, message-oriented and so on), it is an easy candidate for the cloud. Moving these apps preserves their stateless contract, helping to further isolate their logic and more easily black-box unit test them. The benefits are often higher-quality services and applications, and a more iterative development and deployment process. For example, once moved to the cloud, the decoupled nature of the related services allows them to be revised and deployed according to their own independent schedule, decreasing the number of dependencies within a single application.

·         Data intensiveness: Software components that are data intensive (particularly around CPU loads) and thus usually requiring extensive database access can be moved to the cloud with many benefits. For instance, the cloud abstracts database access and hides it from the consuming application, as opposed to having access to a database scattered throughout your application. It also helps to provide increased scalability and performance, as you can scale and distribute a cloud-based service more easily than a database server.. Third-party technology, especially open source packages such as Terracotta's Ehcache, can yield benefits only when the applicable logic is moved to the cloud. If abstraction and independent caching can help your application performance, moving the applicable components to the cloud can quickly achieve this.

Administration

Crossing the boundary between business and technical reasoning, ease of administration is another factor to be considered when determining what can be moved to the cloud. For example, the cloud can help to remotely deploy, administer and configure individual components in new ways. Existing third-party software, such as CA Technologies' IT Management Software as a Service (SaaS) — is a good example of this.

Often, managing smaller, individual portions of otherwise monolithic applications in the cloud ensures quicker deployment, lower costs and greater system uptime. Simply put, if moving a component to the cloud helps you outsource its management, the cost savings over time can justify your decision. Centralizing administration in this way also serves as a gateway in your architecture, helping to fight duplication and wasted effort reinventing the wheel.

We’d love to hear about your own considerations around moving workloads to the cloud, both on the business side as we last discussed and on the technical end. Please weigh in on what factors into your discussions around business, technical and administration issues.

Based on my observations, too many companies initially decide to adopt a technology because they fall for the hype surrounding it. They simply do something because their peers are doing it. This may be the real driving force behind Malcolm Gladwell's book, The Tipping Point (2002), but it seems obvious that it’s not a good reason to build a cloud strategy.

I wrote a few weeks back about revisiting your cloud strategy if you already have such efforts under way, but let’s back up that truck a few feet and consider things from the perspective of those just diving in. While the previous article posed a series of questions about cloud architecture strategies to help newcomers, they also can benefit from reading this one first to better set the context. (Also, let me direct you to an article that’s recently been posted on developing a cloud and mobile strategy that will facilitate the interconnection of those two ecosystems, here,)

So, when it comes to beginning to architect your cloud strategy, you first need to determine what you want from the cloud: whether it will be public or private or even hybrid; what components in your architecture are candidates; and then how to deploy, monitor and administer your cloud services. Many organizations prefer a private cloud for more sensitive requirements, such as a human resources application and personnel data. Some might find a public cloud more appropriate for an internal commodity service or one that they can offer to partners or customers, perhaps even one for which they may charge a fee to access. Hybrid clouds are generally considered to be some combination of public and private services, where an end-to-end process lives across both infrastructures.

Starting from the premise that as an enterprise architect you already have a holistic understanding of your corporate architecture, the next job is to make some important business decisions to identify workloads to move to the public cloud. Then, it's time to focus on the technology.

Business First!

When determining which services should go into the cloud, you need to fully understand the business opportunities behind the moves. The first step to take is to have a business discussion where the following questions are asked:

• Are we building an online application? If not, should we be?
• How quickly must this service go live to capitalize on a business opportunity or meet a challenge?
• What funding constraints are we working under?
• Does the application involve collaboration and sharing?
• Are there business opportunities for the services in the cloud beyond your own applications that use those services?

The answer to the first question should be straightforward, but you need to explore all avenues of your application. For instance, even if it's not strictly a Web application, how much of your application can be self-administered by users (your customers) over the Web? By making more of the admin functions self-serve, you not only may be able to save call-center costs, but your users may prefer it. However, providing this service will require you to place this functionality in the cloud, since more users will need access to it. Doing this has direct consequences in terms of authentication, authorization and security in general.

Questions two and three always rise to the fore in a cloud discussion. Obviously, the cloud is a fast and cheap (at least in so far as upfront costs are concerned) way to get access to infinitely scalable resources. If you’re facing an unexpected competitive threat, you may very well need to step on the gas – and the cloud gives you that capacity and avoid the internal rigamarole of requisitioning, testing and deployment, even assuming the business was willing to give you all the money you need as quickly as you need it to support a launch. In other instances, however, there may be less pressure to move quickly, and putting in the effort to build the internal infrastructure may prove out to have been a more cost-efficient down the road.

If your application requires collaboration between different users, groups or entire organizations, then a cloud solution is a good decision, whether you build it yourself for a specific function or leverage what already exists for mainstream requirements. For example, Google Apps is an excellent example, even for large organizations, allowing easy collaboration for documents, spreadsheets and presentations. Placing these applications in the cloud was previously impossible, and the results have had a direct business impact for both Google (positive) — and Microsoft (not so much).

Regarding the next point, don't be selfish. Ask yourself whether other business groups in your organization can benefit from the services you place in the cloud. Corporate reuse of existing applications has been a goal of almost every enterprise since the 1980s, with the hope of cost savings and increased return on investment. The cloud is delivering on this promise by helping us think about reuse during the design phase, instead of after applications have been built and deployed. Furthermore, ask whether your company can find new business opportunities by offering paid access to some of your valuable cloud services.

In the next blog (available here), I will explore the technical reasons to help determine which parts of your applications should go into the cloud. Stay tuned!

Based on my observations, too many companies initially decide to adopt a technology because they fall for the hype surrounding it. They simply do something because their peers are doing it. This may be the real driving force behind Malcolm Gladwell's book, The Tipping Point (2002), but it seems obvious that it’s not a good reason to build a cloud strategy.

I wrote a few weeks back about revisiting your cloud strategy if you already have such efforts under way, but let’s back up that truck a few feet and consider things from the perspective of those just diving in. While the previous article posed a series of questions about cloud architecture strategies to help newcomers, they also can benefit from reading this one first to better set the context. (Also, let me direct you to an article that’s recently been posted on developing a cloud and mobile strategy that will facilitate the interconnection of those two ecosystems, here,)

So, when it comes to beginning to architect your cloud strategy, you first need to determine what you want from the cloud: whether it will be public or private or even hybrid; what components in your architecture are candidates; and then how to deploy, monitor and administer your cloud services. Many organizations prefer a private cloud for more sensitive requirements, such as a human resources application and personnel data. Some might find a public cloud more appropriate for an internal commodity service or one that they can offer to partners or customers, perhaps even one for which they may charge a fee to access. Hybrid clouds are generally considered to be some combination of public and private services, where an end-to-end process lives across both infrastructures.

Starting from the premise that as an enterprise architect you already have a holistic understanding of your corporate architecture, the next job is to make some important business decisions to identify workloads to move to the public cloud. Then, it's time to focus on the technology.

Business First!

When determining which services should go into the cloud, you need to fully understand the business opportunities behind the moves. The first step to take is to have a business discussion where the following questions are asked:

• Are we building an online application? If not, should we be?
• How quickly must this service go live to capitalize on a business opportunity or meet a challenge?
• What funding constraints are we working under?
• Does the application involve collaboration and sharing?
• How quickly must this service go live?
• What funding constraints are we working under?
• Are there business opportunities for the services in the cloud beyond your own applications that use those services?

The answer to the first question should be straightforward, but you need to explore all avenues of your application. For instance, even if it's not strictly a Web application, how much of your application can be self-administered by users (your customers) over the Web? By making more of the admin functions self-serve, you not only may be able to save call-center costs, but your users may prefer it. However, providing this service will require you to place this functionality in the cloud, since more users will need access to it. Doing this has direct consequences in terms of authentication, authorization and security in general.

Questions two and three always rise to the fore in a cloud discussion. Obviously, the cloud is a fast and cheap (at least in so far as upfront costs are concerned) way to get access to infinitely scalable resources. If you’re facing an unexpected competitive threat, you may very well need to step on the gas – and the cloud gives you that capacity and avoid the internal rigamarole of requisitioning, testing and deployment, even assuming the business was willing to give you all the money you need as quickly as you need it to support a launch. In other instances, however, there may be less pressure to move quickly, and putting in the effort to build the internal infrastructure may prove out to have been a more cost-efficient down the road.

If your application requires collaboration between different users, groups or entire organizations, then a cloud solution is a good decision, whether you build it yourself for a specific function or leverage what already exists for mainstream requirements. For example, Google Apps is an excellent example, even for large organizations, allowing easy collaboration for documents, spreadsheets and presentations. Placing these applications in the cloud was previously impossible, and the results have had a direct business impact for both Google (positive) — and Microsoft (not so much).

Regarding the next point, don't be selfish. Ask yourself whether other business groups in your organization can benefit from the services you place in the cloud. Corporate reuse of existing applications has been a goal of almost every enterprise since the 1980s, with the hope of cost savings and increased return on investment. The cloud is delivering on this promise by helping us think about reuse during the design phase, instead of after applications have been built and deployed. Furthermore, ask whether your company can find new business opportunities by offering paid access to some of your valuable cloud services.

In the next blog, I will explore the technical reasons to help determine which parts of your applications should go into the cloud. Stay tuned!

I came across two reports in the same day with very different outlooks on enterprise architecture in the U.S. federal government — one with high expectations, and one with some chastened hopes.

Since I always like to start with the bad news, on the theory that a real downer following an adrenaline rush can’t be a good thing for the heart, let’s turn first to a recent report by Stanley B. Gaver of Technology Matters Inc. Entitled “Why Doesn’t the Federal Enterprise Architecture Work?" and available at this blog, the piece was written late last year and has been four years in the making. It is based on research as well as observations about enterprise architecture at six U.S. government agencies. Apparently, the work wasn’t easy for Gaver to write, since he himself believes in EA as a way to correct the duplication and redundancy he saw as a federal IT worker for 30 years.

So, what’s wrong with federal EA practices? Gaver points, as reflecting his own work, to an October 2010 Federal CIO Council report citing concerns about the future of federal EA programs which, the report said, are still bedeviled by issues such as a lack of shared understanding and confusion over where EA resides. From there, he goes on to enumerate his specific concerns, including:

• Using the term FEA (Federal Enterprise Architecture) models has created massive confusion. Referring to them as such blurs understanding of a simple idea of having five standard taxonomies to categorize investments, performance measures, and IT resources uniformly across the federal government. Additionally, further confusion resulted because few actually knew exactly how the FEA reference models fit into and related to the entire Federal Enterprise Architecture program or that the reference models are not the same as the FEA itself.

• At the agency level, lack of a common enterprise architecture repository model and lack of department-wide integration contributed to producing little of real value. Program management by the Office of Management and Budget (OMB) and compliance activities were time-consuming and confused by complex and subjective assessment criteria. Gaver’s report notes that, “at least until very recently, federal agencies were required to submit two quarterly reports, the Enterprise Architecture Assessment Framework (EAAF) report and the Enterprise Architecture Segment Report (EASR), to OMB to report on the status of their respective Enterprise Architecture programs.” (To that, I’ll add that enterprise architects themselves were known to complain that rather than really leveraging enterprise architecture to improve the mission of an enterprise that touches some 300 million people — the good old U.S. of A. — their work seemed to have become relegated to a compliance-only activity.)

• At the federal level, the Federal Enterprise Architecture Management System (FEAMS) failed, and so failed to serve as the foundation of the entire Federal Enterprise Architecture. Worse yet, Gaver notes, “what also hasn‘t been understood is that FEAMS was actually just one of a series of related but disjointed efforts to collect and integrate EA data” and that all of these efforts focused only on subsets of data that were originally supposed to have been  included in the FEAMS system.

I could go on, as Gaver certainly does, pointing out problems. One of them, for instance, is that the regression of EA maturities “should have been a red flag indicating that there were significant underlying problems with the federal EA program.”

All Is Not Lost

We could use a little good news right now, and Gaver gives us some. He does believe that the federal enterprise architecture can be rehabilitated. What’s required is taking it out of its “swamp of sloppy definitions and misused words, grand definitions of architecture that too often have little or nothing to do with real architecture, and poorly differentiated functionality, all currently lumped indiscriminately under a common and misnamed banner.”

In spite of its own failures, he says, the Federal Enterprise Architecture program has led to some successes, with some agencies managing and modernizing their IT resources. In addition, a couple of dozen e-government initiatives are what Gaver calls by-products of a key notion of enterprise architecture. 

In fact, when it comes to open government, enterprise architecture is setting itself up to fulfill some high hopes. In the second report I referred to, “An Open Government Implementation Model: Moving to Increased Public Engagement” (2011), sponsored by the IBM Center for the Business of Government, authors Gwanhoo Lee of the Kogod School of Business at American University and Young Hoon Kwak at the School of Business at The George Washington University say that establishing enterprise architecture early on is key to successful open government initiatives. Efforts such as the open government portal of the Department of Health and Human Services and the Centers for Medicare and Medicaid Services’ dashboard are leading the way.

As more sophisticated portals come on line, management complexity also grows, and could inhibit their sustainability, the authors write. They advise: “Agencies need to develop high-level enterprise architecture in the early stages of their open-government implementation and standardize, simplify, and integrate data, tools, systems, and pro­cesses wherever possible.”

While EA makes up only a small part of the discussion in this paper, it clearly holds a prominent position in getting agencies from the point of increasing data transparency, to improving open participation and collaboration by citizens, to an era of ubiquitous engagement both through mobile tools and seamless integration of methods, tools and services within and across government agencies. 

My conclusion from reading the two reports is that the rehabilitation Gaver speaks of had better start soon if enterprise architecture is to be a strong foundation for broader government efforts. Do you agree?

Defining an enterprise architecture is a process that’s distinct from software development. But applying some methodology principles of agile development can help when crafting an architecture. 

So let’s explore a bit about what the agile process is and how and why it might help the enterprise architect function. The agile software methodology is based on an iterative and incremental development approach aimed at improving quality and time to market. Reaching those ends certainly would be nice for the enterprise architect, as the process in large organizations often has a reputation of being slow and arduous. Too often, by the time individual architectures and plans are complete, the problem domains or technologies they target have evolved. This can result in a rolling architectural initiative, where the architecture is neither complete, nor fully implemented, at the points in time when it’s needed most.

How can agile be applied? Start with its principle of organizing smaller, cross-functional teams. One of the problems with some enterprise architecture organizations is that they work in silos, where one person or group does just data architecture, another does business architecture, and so on, with little collaboration or “big picture” vision of how systems and processes will interact across their respective boundaries. The agile methodology aims to correct that, without being so rigid.

Core responsibilities, as defined by The Open Group Architecture Framework (TOGAF), don’t change. The business architect (a.k.a. business analyst) still defines and documents business processes. The application architect still designs applications and components to match the business architecture. The data architect (also called a database designer, but not the database administrator) still defines the databases and entities stored within them. The technical architect (sometimes called a data center architect, or network architect) still builds the hardware and software environments to house the applications and solutions. But now these tasks will be done in the context of all the systems being built, under the chief enterprise architect’s oversight, rather than in a vacuum.

To support collaboration among these cross-functional teams requires definition of a documentation format, and an overall system cartography. This involves Unified Modeling Language (UML) tools, as well as data modeling tools such as CA Technologies' ERwinâ Data Modeler. Defining entities and relationships in UML is only one part of the architecture, after all. The data model is crucial to determining what entities exist, and where they should be placed (i.e., in the cloud, in the data center, on a provisioned mobile device, or elsewhere).

Once you have the collaboration support requirements in place, it’s time to actually define the interfaces between systems. Just as in agile software development, the agile methodology applied to good architecture works on the premise that separate software systems communicate through well-defined interfaces, otherwise known as “contracts.”

The Agile Architecture Discipline

To summarize, here’s how the agile software methodology can be applied to architecture:

• Create teams of architects, with focused expertise (i.e., data modeling), applied broadly.
• Release architecture artifacts often, with small, flexible iterations that last no more than four weeks.
• Agree on a documentation standard that includes industry-accepted tools such as UML, Entity Relationship Diagrams with ERwin, and so on.
• Work closely with development, preferring constant casual communication over more formal procedures (i.e., tossing documents over the wall).
• Support alternative architectures and teams (for the same business problems) with deliverables.

For more on the subject, as well as alternatives, read Paula Klein's discussion of lean methodologies, the Agile Manifestoor Scott Ambler's essays on the Enterprise Unified Process.

I thought I’d share with you some insights gleaned from a recent Gartner online event hosted by its VP and Distinguished Analyst, Betsy Burton, who leads the firm’s enterprise business architecture research. Burton gave an excellent presentation on the best and worst enterprise architecture practices. Among her many talking points, I’ve commented on a few that really resonated with me — I hope they will for you, too.

● Take the Bull by the Horns. So often I hear complaints from the enterprise architecture community that part of the challenge in delivering on an enterprise strategy is a lack of clear definition by senior management. Burton weighs in here with the advice to stop the blame game. Be proactive and start to figure out for yourself what that strategy is, she says. For example, you can research public statements your company has made or find documents it has released. Use those as a guide for crafting what you believe the business strategy to be. It’s OK if you don’t have it down to a ‘T’, but having something to guide your execution and your communications with business execs is a strong start. And, those execs will be more likely to review and revise a proposal than to sit down and do the work from a blank slate. 

● Know Thy Customer. Ask an enterprise architecture team who their customer is, as Burton has done, and the answer may well be, “the business.” That’s the wrong way to look at things, she says. The business is your partner — the folks you are working with to support the real end customer, be that consumer, citizen or other businesses. This subtle change in thinking matters for many reasons. One of them, as I see it, is that there’s power in the psychological shift — when you start thinking about the business as a partner you work with, rather than a as customer you must service, you’re involved and invested in a relationship of equals. And this type of business relationship is the only kind that really succeeds over the long term to drive customer value.

● Standards Are Good, to a Point. Then, not so much. Standardizing everything is less the Holy Grail than it is the Crusades. In other words, don’t wind up waging a series of campaigns that never actually achieve your end goal of controlling what you really must control. I loved Burton’s image of people in “overstandardized” organizations swatting those standards away like flies! Instead, she says, only emphasize the standards that you need people to pay attention to, and that are really critical to the business.

● Bring Real Measurements to the Table. It doesn’t matter if business people or senior managers understand the work you actually do as an enterprise architect; what matters is whether they understand what you do for the enterprise. You know, for instance, that one of your roles is to synthesize and deliver guidance on emerging business- and IT-driven solutions, which leads to reducing investment risk and maximizing business impact. To explain that value in more concrete terms, give your senior managers metrics they understand — your efforts to maximize service, for instance, can be linked back to market coverage index metrics. You don’t need to show precise percentages, just relationships to the bigger business performance metrics picture the business cares about.

There were about 10 best and 13 worst practices covered in Burton’s webinar, and I encourage you to visit Gartner’s webinar archive for the full presentation.