THE PURPOSE OF ENTERPRISE ARCHITECTURE

by Oliver Sims, Senior Consultant, Cutter Consortium

Recently, I talked with several senior IT executives who, in different ways, asked about the purpose of enterprise architecture (EA). Now, "What's EA's purpose?" is a good question because it asks what the value of EA is and how that value can be measured.

Among the many companies that practice it, EA is widely seen as a "public good." But a public good is no good at all unless it's delivered and is perceived as adding measurable value to recipients. So how do you deliver an EA? To whom? And what's the value?

Over the past five years or so, several architectural approaches, concepts, and practices have come together in a surprisingly synergistic way. As a result, we are beginning to see specific answers to questions about the usefulness of EA.

In this Executive Update, I'll begin by giving my own answer and then providing support for it. In so doing, we'll try to gain some perspective on EA. Then I'll outline the elements that enable this answer to become much more than a pipe dream. But this discussion invites another question: "If the answer is sitting there waiting to be applied, why hasn't the solution already happened all over the place?" Answering this question forms the final part of this Update.

A short disclaimer: EA encompasses a wide field. Here, I am setting my scope on what many view as the heart of EA -- that is, the entire area of development activity, whether it is application design and building, configuration of commercially available packaged software, legacy or new service integration with enterprise application integration (EAI) tools, business process management (BPM) or workflow specifications, regardless of whether inhouse or outsourced, from business requirements through to deployment. For brevity, I'll refer to this area as simply "application development."¹

WHAT'S EA'S PURPOSE?

Goals set for IT by the business are often phrased in terms such as "time to market," "responsiveness," "agility," and "flexibility." One CEO told me that his plans required that his company's IT department improve tenfold in responsiveness: such as, for example, the time between a request made of IT for new or modified system capability and the delivery of that capability to business users.

How do we achieve such goals? Well, someone has to design a way to do so. That someone is the enterprise architect. If goals like these are taken seriously, EA has to design a no-magic way of achieving them. Thus, the purpose of EA is to design an IT development environment that enables development projects to meet, and be viewed as meeting, the goals set for IT by the business.

Designing such an environment is no small task. It includes a host of things: the application portfolio, the IT planning process, the target runtime environment, development tools, middleware, databases, methodologies, requirements, acceptance processes, and so forth, to say nothing of such things as patterns, frameworks, and standards, that are sometimes the limits of an architecture group's remit. In addition, the design of this environment must include the following:

• The metrics whereby achievement relative to goals can be measured
  
  
• A management information system whereby managers (from IT project leader to user management to CEO) can see the degree to which goals are being met and how IT deliverables are aligned with the business
  
  
• The processes to be used within IT such that the goals can be met
  
  

In other areas of the business, requirements for computer support are fed to the IT organization, which then delivers solutions. It is now time to treat ourselves to the same medicine: IT should address its considerable skills and know-how to the complex business area of application development.

How can this be done? To help answer this question, let's first look back and put EA in perspective.

EA IN PERSPECTIVE

Way back, at the beginning of enterprise IT, there was no such role as enterprise architect. For example, during the late 1960s, most enterprise IT systems were simple. They consisted of batch processes, run through a single-threaded computer and written using languages such as COBOL or RPG that were designed for ease of use by the application developer. Many systems had no disks, no operating system, no database management systems (DBMSs), no middleware, and no communications. The main operational challenge was to avoid dropping any of the millions of punch cards or tangling the miles of paper tape. The main installation challenge was to find a room that could be air-conditioned and that had a floor that could bear the weight of the hardware.

Both design and programming were simple. The architecture of batch systems was defined by common usage and experience within the industry, and indeed some languages like RPG had built-in logic, such as complex file matching and merging, level break control, summary output, and report creation. Thus the programmer, who was often also the system designer, did not have to invent this logic anew for every program. Then came online transactional systems, distributed processing using minicomputers, and just when all of this was being brought under control during the early 1980s, along came the PC. After that point, it was one thing after another.

The concern that enterprise IT is akin to a cottage industry has been aired. Indeed, for some time now, many projects have done their own thing regarding architecture, design, choice of tools, testing, team organization, and so on. But if this notion has any truth, it is not surprising, and it is arguably the inevitable outcome of the manic changes we've experienced over the past 30 years. Indeed, there are good reasons why the state of so much enterprise IT development has remained in a cottage industry-like phase. These reasons are fairly well recognized:

• The constant increase in demand for additional applications² over the past 30 years, driven by the immense cost decreases and vast power increases in hardware.
  
  
• Enterprises have not only demanded more applications but, increasingly, faster time to market and responsiveness as well as greater agility and flexibility -- often to support dynamic business evolution where requirements are not as well defined as previously. In other words, business has demanded that IT get off the critical path of business change and evolution.
  
  
• The nature of applications has evolved dramatically, from the simple batch systems of the 1960s to today's networked distributed apps, which are capable of handling much higher transaction volumes.
  
  
• To support and enable new kinds of applications on far more complex hardware configurations, middleware has grown from almost nothing to today's high-performance, high-capability middleware products.
  
  

In summary, IT has not so much evolved as been caught up in a veritable cauldron of change that does not appear ready to abate anytime soon. The rate of change has resulted in a dramatic increase in the level of complexity facing the poor developer, and the distinct enterprise architect role evolved as a major aspect of the strategy to handle this complexity and to gain a grip on the torrent of market-driven technology innovation. And that's to say nothing of the fast-changing business environment, where subject matter experts (SMEs) in the business require IT to deliver increasingly complex business logic.

A major EA focus has been on reducing the complexity inherent in software technology. To this end, EA groups have produced patterns, frameworks, and guidance on how development projects should address such technical issues as scalability, transactional integrity, security, application modularization, performance, data handling, interface design, and so forth. However, as Figure 1 illustrates, there is a problem with this strategy. In the figure, the solid lines indicate the general organizational structure, and the dotted arrow shows artifact delivery.

Figure 1 -- Organizational structure and product delivery.

The problem is, how does an EA group actually deliver its products to development teams (the question mark in Figure 1)? Often EA products come in the form of either small software modules that help with a particular problem or Web-based (or even hard-copy) manuals. Too often, development teams ask, "How do I use this module, why does it help, and how do I integrate it with my stuff? Oh dash it, it'll take too long to learn -- I'll just write my own." The result is yet another "useful" module that in reality isn't useful because it's too time-consuming (or difficult) to use. Or developers ask, "This pattern is great -- I understand what it does -- but how do I apply it with my particular set of classes, written in language X, and modularized in the way I prefer? Oh what the heck, I'll just do what I did before."

In other words, EA products often pose a usability problem, so they're not used (or not nearly as much as they should be). And projects continue to do a great deal of work that is duplicated -- often in only slightly different ways -- in other projects. Much of this duplication involves dealing with software technology, tool setup and use, a multitude of detail-level design and code decisions, aspects of project management, processes, and so forth. Figure 1 illustrates this overlap through the gradient under development projects. Each project deals with both business logic (the light-colored portion of the top of each project box) mixed in with tool, technology, and other issues indicated by the darker shading toward the bottom of each project box.

ENABLING ELEMENTS

Now the question appears to be, "How do we make EA products usable?" The first thing is to focus on the "user" -- that is, the application developer (integrator, configurer, business process specifier, etc.). EA needs to produce artifacts that are obviously and immediately helpful to development people. This sounds like comments heard within the business, such as, "We need an application that will be obviously and immediately helpful to the warehousing people." In this case, the warehousing SMEs will soon receive the attention of business analysts, who will define a set of warehousing requirements, which in turn will be satisfied by the production of an integrated computer application suite by IT architects, designers, and developers.

Perhaps we need to take a dose of our own medicine. After all, the business function, which is application development, is surely too important to the business not to receive the same support. But who are the SMEs? Certainly enterprise architects figure large among their number. It is they who understand the kinds of artifacts that development must produce and how they should be structured. And to a large extent, enterprise architects can also fill the role of the business analyst who analyzes the business of application development.

So we conclude that enterprise architects should be designers of the complex application that implements the "business function" of application development. In other words, enterprise architects should focus on the design of application development applications. Now, "application development application" is difficult to say. Another term might be "extended integrated development environment," or XIDE.³ So the job of architects is to design (and evolve the design of) an extensive and integrated development environment.

Core Concepts

The set of core concepts that enable the building of such an environment has been around for several years and enjoys support from a large number of enterprise architects. Only recently, however, has an understanding of how these concepts form a mutually supportive framework developed. The core architectural enabling concepts are the following:

• Architectural styles
  
  
• Separation of business logic concerns from software technology concerns
  
  
• Model-driven development (MDD)
  
  
• Component-based development (CBD) for service implementation
  
  
• Direct traceability between business requirements and IT software structures
  
  

Architectural Styles

Today, the existence of definable "architectural styles," each applicable to many different applications, is generally accepted.⁴ An architectural style, also the basis of a "product line,"⁵ is essentially a specific system structure, such as service-oriented distributed business systems, GUI- oriented application builders with back-end DBMSs, batch systems, impenetrable legacy systems, genuinely single-user systems, and embedded real-time systems. Capturing a given architectural style involves specifying distribution tiers, business function layers, modularization strategies, granularity scheme, data type representations, specific software bindings, error management, event management, transaction management, frameworks and patterns, overall application structure, model structures, scalability rules, dependency management rules, naming standards, test cases and test data generation, and so forth.

Designing according to an architectural style that is "pre-canned" in tools and processes can greatly ease the burden on application developers.

However, perhaps the most important aspect of capturing and specifying an architectural style is that it should palpably illustrate how production systems will satisfy stakeholders' nonfunctional objectives, such as performance, scalability, and other "ilities."

Business-Technology Separation

An architectural style defines a specific class of platform with specific platform services. However, a well-specified architectural style by itself may not handle one of the most important separations of concern: separation of business logic from software technology. This separation is key to handling technology churn and to simplifying the job of application development by delivering technology transparencies. The "software factory" approach^{6, 7} targets precisely this separation of concerns (product line practices also directly address architectural style).

CBD

CBD is sometimes viewed as building applications by buying "components" off the shelf and then magically fitting them together. Here, however, I mean a specific software engineering approach to modularization and software structuring that has recently been incorporated into version 2.0 of UML.⁸

This kind of CBD is arguably the best way to construct applications and is extremely effective when used to implement services. But it really comes into its own when (1) an architectural style approach is used, and (2) the style is expressed in two parts following a business-technology separation approach. One part defines the structure of business logic in an application following strict CBD guidelines; the other defines the platform on which the application is to run, using CBD where appropriate. For want of a better term, I call this combination of architectural style, business-technology separation, and CBD "mature CBSE" (component-based software engineering). These three approaches can result in great synergy, and it's hard to tell which of the three contributes most.⁹

Bridging the Business-IT Gap

For IT, an endemic problem is the lack of two-way traceability from the business through business requirements specifications to IT application implementations. In the past few years, however, several techniques have been developed that can provide a direct path from elements in the business through business requirements to services application modules. This offers much greater traceability than previously and can provide for effective impact management as well as better application portfolio planning. Two such approaches¹⁰, ¹¹ depend on the use of mature CBSE in application development. This applies not only to new applications but also to the other forms of development that I grouped under "application development" at the beginning of this Update. For example, existing CBSE disciplines can be profitably used to produce service-oriented legacy wrappers.

Supporting the requirements definition activity is an increase in the idea that a specification done with SMEs can be immediately tested and seen. Business process management and EAI products already provide for this. For core systems that need code to be produced, early prototyping approaches that assist with requirements definition are now being developed.¹²

MDD

The essence of MDD is to move the development effort and the intellectual property inherent in software up the development chain away from code and toward design. The idea is that a rigorous design can become a large part of the "program," with most code being generated automatically. In some limited areas, today's tools can even execute a design model that is computationally complete.¹³ This movement is supported by Model Driven Architecture (MDA) from the Object Management Group (OMG) and work by both Microsoft and IBM on domain-specific language tools¹⁴ that enable IT organizations to create "languages" -- such as, for example, a diagrammatic design language that expresses a particular architectural style is not out of the question.

Tools

The $64,000 question is, "How do you actually implement the five core concepts just described?" Even when the synergy between the core concepts is exploited, the lack of supportive tools has meant that building an XIDE required inordinate effort. And it is clear that few IT organizations today (and few yesterday) have any desire to get into the tool-building business.

But it is equally clear that to succeed in achieving EA's purpose, tools are needed that, for example, enable an architectural style to be defined and then fed into the tool so that application developers need only define the business logic following patterns and structures defined by the architectural style. Further, it would be useful if this style could be mandated so that the tool could check for deviations from the style. Such tools are being developed today, and some vendors already have them on the market.¹⁵

Now that tools are becoming available, there is no reason for IT to remain in the cottage industry phase for much longer. Today's tools, and those about to arrive, make the effort much more affordable. Indeed, a few companies already offer the kinds of services, with perhaps some useful software artifacts to help, that are often needed for an organization to make the leap to an XIDE and to a fundamentally more productive development environment.

So the core concepts are in place, and the tools to implement them will be with us very soon. With good architects focusing their attention on designing the XIDE solution, we can indeed build the killer app: the app that will transform IT application development so that IT can move away from the critical path of business evolution. Today, early adopters can make an effective start. What's stopping us?

MAKING IT HAPPEN

There seem to be two main reasons why few enterprises are thinking about transforming their application development. First, it requires IT management to bring on board a whole new set of ideas when day-to-day pressures are so high and when introducing something new appears so disruptive. Second, it will probably require a change in IT organization.

A way to address the first problem is to use the kind of minimally intrusive "transition" process described in previous Cutter Executive Reports.¹⁶ This process includes a short (six to eight weeks) first phase, where the nature of the change is defined, the value assessed, and a plan for the next phase is produced. There is then a go/no-go point. The second phase starts to develop the concepts in the context of existing projects. During three subsequent phases, the process continues, always in the context of projects that are planned or become planned. Care is taken to show value as soon as possible, and certainly by the end of the second phase. In this way, inevitable changes are managed and controlled.

As illustrated in Figure 2, the second problem is organizational change, where the EA organization designs the XIDE and tests its various capabilities and artifacts in order to ensure that the design is correct. Configurations for development tools are also designed. In addition, EA designs the information system that produces metrics and feedback to management (the main one shown by the bold dashed arrow from the development projects group) and the execution environments. (Since the focus is on application development, the crucial step of application delivery through operations to the business is not shown.)

Figure 2 -- Organizational change and application development.

The tested XIDE design is delivered to an important new group -- the XIDE group, which is responsible for creating the XIDE (much of the work lies in integrating commercially available development tools) in such a way that project teams are eager to use it. This can be problematic because such an organization often cuts across the traditional project-oriented structure. But this change must occur for development projects to have a development environment that conceals as much technology complexity as possible and thus allows as much focus as possible on the business logic only.

SUMMARY

In this Update, I've argued that EA's aim is to help achieve IT's goals by designing an environment that significantly reduces the effort in developing flexible business applications. EA carries the prime responsibility for this, and as such, its purpose is to design and test the XIDE -- the "application" for the business function of application development -- that is necessary for IT to meet its goals of time to market, responsiveness, agility, flexibility, and quality. As part of this, EA has the following responsibilities:

• To focus on delivering technical simplicity and productivity to members of development projects (SMEs, designers, developers, project managers, testers, etc.), thus enabling projects to concentrate on "the business."
  
  
• To ensure that development processes are focused on applying the architecture and producing business applications that conform to extra-functional requirements (the "ilities").
  
  
• To design traceability and project performance applications for stakeholders and IT management (including project managers)
  
  
• To design the processes and advise the organization on how to implement these designs
  
  

EA, then, has a bright, if challenging, future. Its success will be measured directly by the improvement its designs achieve, whether measured by time to market, responsiveness, agility, or flexibility of application development projects.

ENDNOTES

¹EA addresses a broader area than this, as described by Cutter Business Technology Council Fellow Ken Orr in " The Three Faces of Enterprise Architecture" (Cutter Consortium Enterprise Architecture Executive Report, Vol. 7, No. 1, 2004). However, pursuing the purpose of EA presented here takes one into this wider area, depending on the nature of the enterprise.

²By "applications," I mean not only new applications designed and built inhouse but all forms of development, including design for outsourced applications (and the building of those applications), BPM and workflow implementations, bought-in applications that need to be configured, and so forth.

³This term is taken from Herzum Software COSM (www.herzumsoftware.com).

⁴For example, see Hubert, Richard. Convergent Architecture: Building Model-Driven J2EE Systems with UML. Wiley, 2002.

⁵See the Software Engineering Institute's Product Line Practice (PLP) Initiative (www.sei.cmu.edu/plp).

⁶Herzum, Peter, and Oliver Sims. Business Component Factory: A Comprehensive Overview of Component- Based Development for the Enterprise. Wiley, 2000

⁷Greenfield, Jack et al. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools. Wiley, 2004.

⁸OMG. UML 2.0 Superstructure Specification, ptc/04-10-02, Chapter 8 (www.omg.org).

⁹Some argue that component software is tightly coupled and cannot be used in a loosely coupled service-oriented environment. This may be the case for some component technologies, but mature CBSE is an architectural- and design-level approach that can be mapped onto several different platform technologies, combining (for example) Web services with J2EE technologies.

¹⁰Herzum Software's COSM approach.

¹¹Sims, Oliver. "Service-Oriented Architecture Part 2 -- The Bridge." CBDI Journal, 9 April 2003.

¹²For example, both New Technology/enterprise's JeeWiz (www.jeewiz.com/big_process.html) and Richard Pawson's Naked Objects (www.nakedobjects.org) provide for early prototyping as a part of requirements definition.

¹³See, for example, www.kc.com.

¹⁴Sims, Oliver. " DSLs Are Coming: Will You Be Ready?" Cutter Consortium Enterprise Architecture Executive Update, Vol. 7, No. 22, 2004.

¹⁵For example, ArcStyler (www.io-software.com) and Objecteering (www.objecteering.com).

¹⁶Guttman, Michael, and Jason Matthews. "Migrating to Enterprise Component Computing" series. Cutter Consortium Enterprise Architecture Executive Reports, Vol. 1, No. 1, 1998; Vol. 2, No. 3; Vol. 2, No. 6; Vol. 2, No. 10, 1999.

ABOUT THE AUTHOR