Enterprise Architecture: It's Not Just For IT Anymore

by Jeroen van Tyn, Senior Consultant, Cutter Consortium; and Mike Rosen, Director, Cutter's Enterprise Architecture Practice

Enterprise architecture (EA) has taken on renewed importance in the past few years. Yet this is in contrast to the fact that EA has largely had a history of failure to deliver on promised value. Much of this disappointment can be traced to a lack of alignment with business drivers and requirements. As enterprise architects, it is incumbent upon us to understand and address these failures and to deliver value that aligns with business goals.

In this Executive Report, we examine EA, taking a close look at why it fails. We discuss why it is necessary and emphasize the importance of EA aligning IT with the business. We distinguish between enterprise business architecture (EBA) and enterprise IT architecture (EITA) and make the case that EBA must be the source of requirements for EITA. We then present a case study from the mortgage industry that outlines a process for developing an enterprise business architecture and its related enterprise IT architecture in tandem.

WHAT IS ENTERPRISE ARCHITECTURE?

While much has been written about enterprise architecture, including many different definitions, there is a reasonable consensus that EA is squarely in the realm of information technology (IT).

Cutter Consortium Senior Consultant Scott Ambler offers the following definition of EA:

An effective enterprise architecture promotes consistency across your organization's systems by guiding development teams towards using a common set of proven approaches to application architecture. This enables both reuse and system integration through common mechanisms and compatible semantics across systems. [2]

Without quibbling about the details, definitions like this are concerned with enterprise application architecture (EAA), that is, "how to design enterprise applications" [7]. However, EAA doesn't address the architecture of the enterprise that the applications are in.

A more useful definition might say that EA is "how to organize multiple applications in an enterprise into a coherent whole" [7]. Because this definition still lies entirely within the IT realm, we'll call it enterprise IT architecture (EITA) for our purposes here, to distinguish it from enterprise business architecture (EBA), which we'll discuss later. Lastly, when we use the term "enterprise architecture" (or EA) here, we're talking generically about architecture at the enterprise level, be it focused on business or technology. For a very good definition of EA that encompasses business and IT, see sidebar "A Broader Sense of Enterprise Architecture."

Who/What Drives EITA?

EITA is typically driven by a central IT architecture group that has responsibility for defining overall architectures for an enterprise. Even in companies that are fairly federated and that have IT organized along business lines, anything resembling EITA is commonly a central IT function.

EITA groups may have some level of business sponsorship, but the executive torchbearer for EITA is usually a CIO or some other highly placed IT director.

EITA groups are often very technology-focused. Major topics of concern include:

• Consolidation and simplification of IT infrastructure (e.g., creating and migrating to standard platforms, databases)

• Data architecture

• IT security architecture

• Definition of IT standards

• Architectural review of IT application and system designs

• Building an IT repository to catalog IT assets, systems, and applications

• Research and prototyping of new technologies

The IT focus of central architecture groups often has a historical basis. In many cases, the first real need for any central IT capabilities grew from a requirement to enable and manage communications and integration across the enterprise -- a network and middleware-level approach. Another motivator for central IT was the management of data centers, which required the deployment of multiple applications in the same environment. As complexity and costs grew, a more systematic approach was needed, leading to the creating of a centralized "architecture" group.

WHY DOES EITA FAIL?

Although central architecture is generally effective in managing the IT infrastructure, enterprise IT architecture efforts often fail to extend their influence beyond that. A recent EITA effort by a global leader in the marketing, travel, and hospitality industries spent US $12 million on service-oriented architecture (SOA) before the project was halted for lack of business ROI. This case is typical of EITA failures, which often progress as follows: The EITA effort is driven by IT management through a central IT architecture group, as discussed above. Not surprisingly, it is business needs that drive the business applications that the EITA seeks to organize. IT management fails to understand the central importance of the business context for EITA. Application business sponsors don't see the value of spending "extra" dollars to have their applications conform to the EITA. And so, the impasse resolves in the only way possible: the EITA initiative is ended.

Why Is This Possible?

A key factor that enables such EITA failures is cost accounting, which sets a strong bias toward local decision making rather than corporate-wide governance. IT cost accounting often pays lots of attention to the pieces (i.e., business applications) while all but ignoring putting the pieces together (i.e., enterprise concerns). Business application owners pay directly for implementing their applications, so they have an incentive to drive their costs down. Naturally, anything outside of their immediate sphere is first to be cut.

Business application owners typically do not pay directly or explicitly for maintenance of their applications. Integration is generally dealt with in the same way, and costs for the two are often lumped together in an overall line item for "keeping the IT lights on."

In either case, the true costs incurred by virtue of the fact that applications exist within a larger enterprise context are not examined or accounted for. What passes for maintenance, integration, or production operations often includes reworks and fixes for things like basic data sharing to support necessary interactions with other applications and data stores. Huge amounts of money are spent, for example, to reconcile differences in business semantics and data formats between applications. Because this kind of work is typically not well planned for, it occurs after production rollout and thus ends up in the lump-sum cost accounting.

Breaking out of such an insular perspective and behavior is difficult because, while business application owners may genuinely be doing what they think is best for the company, they often lack the information, perspective, and incentives that would more effectively enable them to assess what is "right" for the enterprise. What's more, business managers have often been trained to believe that worrying about the enterprise is someone else's problem (e.g., IT) and that they aren't empowered to delve into that space. So there's little to propel changes to the way for which all of this is accounted.

The point is that what is commonly billed as "maintenance" and/or "production operations" IT costs often has a large component attributable to the fact that applications are not islands but rather are part of a shared enterprise that requires enterprise behavior of those applications.

The fallout from all of this is that business application owners don't have the proper grounding for making choices that are enterprise-focused. And not being held accountable for downstream costs can easily lead to suboptimal IT choices, such as purchasing proprietary vendor solutions, which only add to the hidden costs of supporting the enterprise.

IT's Answer to This Is Misplaced

The IT response to all of this is to try to convince the business that EITA has business value. There are two main types of benefits to sell: cost containment and opportunity creation.

Cost containment can be used effectively up to a point in terms of IT operations in that one can show how physical and logical redundancies can be consolidated and streamlined. The return from such an approach is limited to the savings one can realize from lowering IT's operating costs. So while cost containment is certainly a worthwhile and necessary goal, it contributes nothing toward aligning IT to the business.

Yet the trade press persistently touts IT as strategic -- as business-enabling. So opportunity creation is the holy grail that promises to put IT strategy (and its strategic assets such as EITA) on par with business strategy in terms of creating profits.

This is a predictably hard sell because, absent clear business drivers, IT is left to quantify the value of EITA in terms of business ROI or similar measures. One need only do a cursory search to find that even the applicability, let alone the successful application, of such traditional measures to EITA is hotly debated in the industry.

Selling EITA to the business thus ends in failure. The magnitude is further compounded because the investment that IT has already made in EITA technologies, such as application servers, middleware, enterprise service buses, and so on, becomes unused or underutilized.

The common IT lament attributes such failures to politics, and we all just throw our hands up in the air. Or at best, we attempt to follow Martin Fowler's advice and try, as an EITA group, to understand the value of EA and then to minimize the cost to business application owners [7]. But quantifying the value of EA is difficult, as we've seen above, and minimizing cost is a crapshoot because business prioritization isn't driving EITA decision making in the first place.

Now while the vagaries of competing interests are certainly political, such an analysis entirely misses the point that business prioritization is not driving EITA decision making. It is the business that must understand the value of EITA, and to do so EITA of necessity must be defined in business, not IT, terms. We need to move the debate out of the chasm between business and IT and place it squarely in the business realm. It is our thesis here that this will enable companies to properly frame their IT strategy in terms of business priorities, thus markedly shifting the balance of EITA's expected value away from cost containment and toward opportunity creation.

IS EITA NECESSARY?

This is not a glib question; certainly there is no consensus on this among IT experts. For example, one could reasonably argue that the overall thrust of agile methods tells us that good design, refactoring, and attention to user requirements can somehow supplant the need for a deliberate, planned approach to enterprise IT concerns.

Agile methods are themselves a response to some other common IT failures (e.g., the inability to completely capture all requirements up front). Even with the best capture of requirements and delivery of a system to those requirements, business users end up with a system that is what they asked for but is not what they really want or need. But the more relevant failure is the inadequacy of waterfall or other large planning approaches to respond to changes in scope, requirements, and technologies. This leads to incorrect initial estimates and project overruns. It is no coincidence that central IT groups are often proponents of big planning approaches because it is easy to fit additional concerns into the process.

It should be noted that it is not the inclusion of enterprise concerns that causes the process to fail, but rather the process itself. For example, we see nothing incompatible with agile methods and enterprise architecture [13]. It seems that EITA has hitched its cart to the wrong horse.

Yet our definition of EITA is based on the recognition that applications within an enterprise need to interrelate. The very fact that applications exist within the same enterprise means that they serve some larger purpose -- that they exist in a larger context.

One could argue that in any business enterprise, applications must:

• Support business processes that participate in an enterprise value chain, requiring those applications to exchange information, which in turn necessitates common business semantics

• Provide information that is used in aggregate form to support executive decision making, requiring the ability to correlate and combine information from disparate applications, which in turn necessitates common business semantics

However, who can argue with the pain felt due to the failure, or low success, of getting applications organized into a coherent whole? A familiar refrain among business owners of any enterprise application is that they "can't get their data" from some other owner's application. Such operational impediments are obvious hits on IT cost containment.

As to opportunity creation, business agility itself demands agility at an enterprise level. Who would argue that business agility ends at some organizational boundary within a business enterprise? And who would argue that IT can afford to constrain its focus to a picture that is smaller than the business enterprise it seeks to support and enable?

So what we need is a different story for where EITA's marching orders come from.

EA MUST ALIGN IT WITH THE BUSINESS

Aligning IT with the business is almost a cliche: there is no serious argument with this IT maxim, which is often stated as the primary goal of enterprise architecture initiatives. In practice, it means ensuring that IT efforts support defined business requirements. There are as many different approaches to this as there are to EA itself, as the following list illustrates:

• Cutter Senior Consultants Bob Benson, Tom Bugnitz, and William Walton present a process for using a "Strategy-to-Bottom-Line Value Chain" for the development of IT plans and budgets in response to strategic and operational requirements [4].

• Ambler describes an "agile approach to enterprise architecture" in which the architecture is focused on specific projects and is built up over time as more and more projects are accomplished [1].

• The Rational Unified Process (RUP) focuses on the development of single applications but does not go into enterprise architecture or concerns [10].

• Ambler defines enterprise extensions to RUP, which include business modeling and enterprise architecture in the overall application development process [2].

• In the definitive book on Model Driven Architecture (MDA), David Frankel describes how the highest level of abstraction, the "business model" (or computationally independent model in MDA parlance), encourages alignment by removing IT concerns from the business discussion but in such a way that naturally leads to IT concepts in the "application model" [8].

• In Enterprise Patterns and MDA, Jim Arlow and Ila Neustadt describe some extremely useful patterns for enterprise business archetypes but do not delve into the role of EA in the use or development of the patterns [3].

• Carol O'Rourke, Neal Fishman, and Warren Selkow describe in gory detail the history, motivation, and organization as well as how to fill out the Zachman Framework for Enterprise Architecture and its relation to the business [12].

In practice, IT-to-business alignment is typically application-focused: there is almost no discussion in the IT industry regarding business requirements for the EA itself.

It is precisely this lack of focus on business requirements for EITA that is at the heart of EITA failure. For some unknown reason, we as an IT industry routinely ignore our own hard-learned lesson that IT without clear business drivers, requirements, and direction is doomed.

THE BUSINESS OWNS BUSINESS REQUIREMENTS

There is another corollary maxim when it comes to IT business applications. Nobody argues that the business should validate the business value of applications and should define and own the business requirements of those applications. It would seem to follow that the business should validate the business value of EITA and should define and own the business requirements for EITA. And yet, recalling the typical scenario described above, we have IT people trying to sell the business value of EITA to the very business that should be driving the business need for EITA in the first place.

In a phrase, the business owns the problem space, and IT owns the solution space. This is no different for EITA than it is for enterprise application architecture, or for any given application, for that matter. Thus if EITA is to succeed, it must be based on business requirements, which must be defined and owned by the business.

One might see this as a conundrum: where EITA has an enterprise focus and viewpoint, the business people that IT talks to for requirements seemingly have a much narrower focus and thus can't be relied upon to provide enterprise requirements. While on the surface this may describe IT's common experience, there are usually deeper layers to the problem (see sidebar "Corporate Disincentives to Enterprise-Focused Behavior").

In any case, to the degree that we, the IT community, have been seeking business requirements for EITA, we've been looking in all the wrong places. On the one hand, we've been talking to business application owners who aren't equipped or motivated to understand the enterprise context. On the other hand, we've routinely failed to seek out those whose job it is to do precisely that.

Every enterprise has someone who not only is responsible for the enterprise view but pays for it as well. It is these people who need to drive "enterprise-wide" business requirements into line-of-business applications. Such people are CEOs, COOs, or CFOs at the corporate level, executive VPs, VPs, or operations directors at the division level, and so on.

It is beyond the scope of this report to delve into the reasons why enterprise-level executives often fail to make enterprise concerns a key part of the measure of, and thus the compensation for, the performance of their direct reports who are responsible for business lines or business areas. Suffice it to say that "if you disagree with the behavior, check the compensation." ¹ We chafe at the refusal of business line or business area leaders to take responsibility for enterprise concerns, and, not surprisingly, they have little incentive to change and/or have paid a price for trying to effect change.

BUSINESS REQUIREMENTS FOR EITA

Even with the participation of business people who are responsible for enterprise concerns, identifying business requirements for EITA is an altogether different pursuit than that of identifying business requirements for applications.

For starters, there's no easily identifiable business user of an EITA. Where the business user is the undisputed source of business requirements for applications in every serious software development methodology from RUP to agile, there is no obvious corollary for EITA. Thus you'll have a hard time eliciting meaningful use cases or user stories as requirements for an EITA.

Requirements for EITA are of necessity abstracted from application requirements across the enterprise. If EITA's job is to organize applications in the enterprise into a coherent whole, it follows that requirements for EITA must derive from the necessity of getting applications to work together. That is, they are the requirements necessitated by the enterprise context itself.

These kinds of requirements will have similarities from application to application and won't typically be concerned with the end-user goals of individual applications.

Here's an example from the mortgage industry: Say that Application A has the responsibility of funding (purchasing) loans and is a source of funded loans for other applications. Application A may have a use case "Fund Loan," with Applications B and C represented by secondary system actors that receive funded loans. The presence of these secondary actors shows that Application A has responsibility for supplying semantic business information (funded loans) to other applications. This may also be accompanied by common nonfunctional specifications for timing, transaction volume, service-level agreement (SLA), and so on.

However, this analysis is from a point-to-point perspective. There is no overall context about what other information sharing or other integration requirements applications B,C, D, and so on, may have. You'd only be able to leverage a general framework for sharing information between applications if you already had an EITA specified and/or in place, which brings us right back to the start: where do you get the requirements for such a beast? The answer is: only by looking at patterns of requirements will you get a picture of the overall enterprise needs. In the above example, looking at patterns in information sharing needs across multiple applications will yield enterprise-level information sharing requirements.

The point here is that the "view from inside the silo," even if you look from inside all of the individual silos, will not yield the kind of requirements needed for an EITA because such a view is from the perspective of "siloed" needs. Requirements for an EITA must specifically focus on the "stuff in between," that is, on patterns of responsibilities that applications have to the enterprise.

Let's look at it from another perspective. We all know that SOA is very much in vogue these days, and that companies left and right are seeking to implement SOA as a strategic architectural solution. So let's look at our argument backwards from the solution side (i.e., the EITA side, where our EITA of choice is SOA).

Let's say you've decided to implement an SOA. Briefly, the point of an SOA is to enable flexible business processes at an enterprise level. This is accomplished by making common business capabilities available as shared addressable services. If we accept that your decision to go with an SOA solution should be based on business requirements, then it follows that you must have requirements along the lines of: "We've identified a set of business functions that appear in multiple parts of the business, and we've found that it's a detriment to the business to not have them consolidated and freely available across the enterprise. Is there a way that we can crack those business functions loose so that we can reuse them?"

That is, if you think that SOA is the answer, then you must have a business need for exposing business services, and thus you must have a set of business services identified that need exposing. If you don't, why are you proposing SOA as a solution in the first place?

Another set of the business requirements for SOA might be something like: "We have a bunch of business processes/units/organizations that we'd like to pretty much leave alone as they are, but there's a certain amount of information they have to share, and it's hurting us that they're not effectively sharing that information. Is there a way we can get them to share information without having to retool our business processes?"

Experience with enterprise applications tells us that both of these are valid and important business concerns. The point is that the requirements need to be stated in business terms by the business unit that is responsible for making them happen.

MODELING FOR A PURPOSE

Thus far, our discussion has taken us through the proposition that EITAs should be based on business requirements and an examination of the kind of information and perspective that such requirements should focus on.

We take a little detour here to discuss modeling. This is important because we're putting a stake in the ground as to the need for business requirements for EITA and because experience tells us that requirements modeling at the enterprise level can often be an exercise in wasted effort if those models don't have a direct tie-in to enterprise solutions and the development lifecycle. Incidentally, we will not present an argument for modeling in general, as the case for modeling has been eminently made by many experts.

So if we are to have useful enterprise-level models that capture useful requirements for EITA, we need to do something different than the stock-in-trade.

In a nutshell, modeling for a purpose is based on the assumption that you have some end goal in mind whenever you create a model. Specifically, you have an understanding of how your model will be used/consumed in the next step of the process, that the model contains only the concepts appropriate for its current level, that the model includes the information required for the next step, and that the model is of a format that supports the process in developing the next step.

This falls in line with the concepts of model-based development and MDA, although in our discussion here we make no pronouncements as to the formality or rigor with which your models should be created or the use of automatic transformations into more specific models. The point is that we take the essence of MDA to be that any given model contains specific abstractions that describe the current level and form the requirements for the next-level-down model, and that the model elements contained in a given model capture specific information that supports refinement to the next level, as you proceed "down the MDA stack" toward design models.

So when we think about modeling requirements for EITA, we want to model things that are concerned with the enterprise context, that show us what our applications need to do to serve the enterprise. At the outset, you can see that modeling the gory details of all your business processes isn't going to necessarily help you. If you accept that applications exist to support business processes, and that EITA needs to organize those applications into a coherent whole, then it follows that what you need to know about the applications that support the business processes is how they interact, not their internal details. So EITA is primarily concerned with what crosses boundaries. An in-place EITA would show how to handle things that cross application boundaries, but the only reason something would cross an application boundary is if some business process that the application supports has a need that is outside of the application's scope.

So if we wave our magic wand and say that, for instance, we have a business process model in place that is mapped onto our applications, the "interesting" stuff from an enterprise perspective would be:

• Where the behavior of a given business process is supported by more than one application, thus necessitating interaction between those applications

• Where two business processes interact, thus necessitating interaction between the applications that support them

Without going into a formal proof here, you can immediately see that there's a whole lot of business process modeling that wouldn't be necessary in order to successfully model the interesting enterprise concerns. In the first instance, you need to know enough about the business process behavior to understand the handoff point where one application interacts with another; details of business process behavior up to that point and beyond that point are likely of less importance. In the second instance, you can focus on the business processes more as conceptual components with interfaces, where the interfaces are what's important; you only need to know enough of the internals to provide proper context for the interfaces.

This is just a small example, and yet an honest look at just about any enterprise business modeling effort will reveal that huge amounts of time are spent creating models that are simply never used. Enterprise business models, whether business process models, business use case models, business entity models, or what have you, routinely gather dust in corporate cubicles as so much shelfware.

Popular software development methodologies offer little comfort. Those software development methodologies that do speak to business modeling for EITA essentially guide us to model the business and then align IT to the model. That is, there is some set of general-purpose business models that can be used to guide the formation and implementation of EITA strategy. Unfortunately, there's little to be found, whether in guidance or in examples, that shows how to do this. What kinds of things in our business models lead us to make EITA decisions?

What's needed is a different way of thinking about and using business models, a way that purposely drives us toward sound EITA. Specifically, this requires an emphasis on more focused, special-purpose business models.

EBA AS REQUIREMENTS FOR EITA

The business requirements model for an enterprise IT architecture should itself be architectural. Remember, this is all about aligning IT to the business. So where an EITA shows what system elements are important and how they interrelate, an enterprise business architecture will show what business elements are important in the business enterprise and how they interrelate. It follows that we can, and should, use and apply all of the analytical methods to EBA modeling that we would to any EITA modeling.

All of this is predicated on business people taking control and ownership of EBA requirements. This means that business people will have to build competency in modeling and in communicating those models.

One may think that all of this modeling nonsense is far too complex for business people to deal with and that it should thus be left to IT people. Aside from the dangers of leaving enterprise business modeling to IT, as discussed above, there's a core fallacy to this argument.

IT has long been seen by business people as complex, perhaps overly complex. And we in the IT industry have done little to dispel this notion. We promise "silver bullets" and at the same time tell business people not to bother their pretty little heads over the intricacies of IT design and implementation because it's just over their heads. Indeed, this has perhaps been used by IT as a shield against reasonable inquiries by business people as to why things cost so much and fail so often. But we say, "Hey, this stuff is complex! Stick with us!"

With the vast variety of robust tools available today, from application servers to middleware to enterprise service buses to integrated development environments, a lot of the "hard stuff" in IT is becoming commoditized. This isn't to belittle the work to be done, but we must admit that we have lots of options these days. Perhaps the plethora of options and combination of technologies is the root of much of the complexity. So one must question whether IT is the source of complexity at all. In fact, any responsible IT effort should be no more complex than the business it seeks to support. That's not to say that IT people aren't guilty of speculative overengineering: such behavior is sometimes rampant, partially with the cover that IT "complexity theory" provides.

But IT will be complex if the business is complex; it's simply not reasonable to expect otherwise. The tools and technology available today can do amazing things, and for the average business enterprise, the capability of technology is simply not a barrier, nor is it what introduces complexity. But look at today's business environments, with businesses demanding agility and adaptability, staging rapid forays into new markets and market segments, dramatically upsizing and downsizing, engaging in mergers and acquisitions, and so on. Can we seriously expect IT to support all of this without being joined at the hip with the business? And, can we seriously expect IT to manage the complexity, which means limiting the options and combinations, without an effective partnership with the business?

If business leaders want to realize the kinds of opportunity creation and cost savings that IT has always promised, they will have to get in the driver's seat. And that means learning to analyze their business, to formulate IT requirements that align with their business strategies and goals, and to express these requirements in a manner that can be acted upon by IT as it sees best. And yes, this does mean building new competencies in the business.

For its part, IT and its leaders must face the fact that they may have to give up some of what they thought was their territory. Look at the IT organizational chart of any medium- or large-sized corporation and you're likely to find business analysts in the tree. The truth is, much of the territory between enterprise business requirements as we know them and enterprise IT solutions is uncharted. We in IT may say that we've covered it, but we haven't; too much unanchored work has happened here, and it's time we all admitted it and put things on a better footing. The perceptive CIO will be glad to relinquish this space, understanding that IT has plenty to do in learning how to partner with the business to formulate IT strategy and design EITA that is coherent with what the business needs and that manages cost and complexity.

What we're advocating here is a true business-IT partnership, much ballyhooed but seldom implemented. What we hope to do here is show some steps for how this could be done.

The point here is that you can't escape the complexity of your business. The only answer is to address complexity where it exists, to understand it at its source, and to then make decisions based on that understanding. Pushing responsibility for handling complexity onto IT is demonstrably doomed to failure.

This is not to say that IT isn't responsible for managing complexity in its own realm; it takes vision, intelligence, experience, and discipline to effectively and efficiently design and implement enterprise-level IT solutions. However, the world is littered with failed IT solutions that were well designed and well implemented, but sank, or were sunk, due to lack of correlation between the IT solutions and the business problems they sought to solve. Neither IT alone nor the business alone can solve the problems. It must be done together. EBA and EITA are part of the tool set that links them.

EBA AND PATTERNS

It can be fairly stated that architecture is inherently concerned with patterns. At the core of architectural thinking is the process of drawing abstractions from large sets of detail; this is itself an example of recognizing patterns. So EBA should be formulated based on enterprise business patterns.

There are many common EITA patterns, such as SOA, portals, message-based integration, intermediaries, and so on. It would reasonably follow that there would be common patterns in the realm of EBA. Unfortunately, if you go out looking for enterprise business patterns, a lot of what you find are actually IT patterns, with some attempt to link them to business imperatives. Very little of what passes for business patterns actually shows business elements and how they interrelate.

For example, IBM's Patterns for e-business [9] are very much focused on technology patterns for integrating software applications via a suite of tools (not surprisingly, IBM tools). While these patterns do reference business drivers, the accompanying models are strictly application topologies.

And a search for business architectures will yield lots of credence to the idea that business architecture is a key foundation for IT architecture, but almost nothing that actually shows business architecture models, let alone how one goes about formulating an EITA based upon them.

It isn't hard to find numerous references to what would appear to be business patterns and/or business architecture. For example, the federated business model is cited in many a business journal; unfortunately it appears that nobody has taken the time to actually describe and draw a picture of what it is.

So what would reasonable patterns for enterprise business architecture look like? We address this in the next section.

Examples of Architectural Business Patterns

There doesn't seem to be a resource of readily available architectural business patterns out there, and we are admittedly not ready to publish that book of patterns here. However, there are recurring architectural themes that can be found in the business world across business domains. Some examples are:

• Federated business model

• Supply chain

• Mass customization

Since our case study (discussed later in the report) draws upon the federated business model, we have developed it as a business pattern and present it here.

The Federated Business Pattern

The federated business model is often cited in business and IT writings, but a definition of it is hard to find. The American Heritage Dictionary of the English Language tells us that the basis of federation is a federal union, in which "sovereign power is divided between a central authority and a number of constituent political units." We use this definition to help us formulate a business pattern for the federated business model and follow it with a case study that uses this pattern.

The Problem

An enterprise is made up of individual, autonomous organizational units. Each unit has value by itself and can be measured on its overall profitability. However, a higher-level value exists at the enterprise level through the combination and collaboration of the individual units.

Collaboration requires the autonomous organizational units within the enterprise to share or exchange resources, such as information. Organizational units thus produce resources consumed by other units, and vice versa. The exchange of the resource between units is critical for the operation of the enterprise as a whole in achieving its higher value or in regulatory compliance or governance. The resources themselves need to be owned and managed, and the exchange of resources needs to be managed and guaranteed.

Figure 1 shows a schematic diagram of a federated business model. The large circle is the enterprise, the black dots are organizations within the enterprise, the lines are avenues of exchange between organizations, and the squares on the lines are resources being exchanged.

The enterprise view differs from the organizational view in that it is all about the lines. An organization-level view is all about one dot and somewhat about lines that touch it. The dots are pretty "hard-shelled" because of their autonomy. So any enterprise solution architecture would have to focus on making the lines work while putting as few demands on the dots as possible. The enterprise, which is the federation, works well to the degree that the lines work well.

The Solution

The enterprise needs to have federated control over the shared resource to ensure its uninterrupted exchange while maintaining maximum flexibility for each organizational unit. Each unit will have to give up some autonomy in order to interconnect and share. The enterprise must carefully balance the federated control with the individual control.

A central authority is established to manage the exchange of resources between each unit. Explicit rules are established to:

• Define the responsibilities of the central authority

• Define the responsibilities of the organizational authorities

• Define the rules of ownership of shared resources

• Define the rules and lingua franca of interaction between units

• Define the lingua franca of shared resources

Figure 2 shows a UML model of the generic solution.

Scenarios

Some common scenarios for the federated business model are:

• Central reporting of the enterprise

• Enterprise-wide business processes that require information exchange between business units, such as a value chain

• Open innovation networks (aka creation networks)

Consequences and Tradeoffs

The rules represent an agreement or contract between the central authority and the individual units. Modification of the rules requires participation and agreement among all parties. This results in:

• Better innovation and agility in the individual units

• Less overall central control

The establishment of the rules must reach the appropriate balance between control and autonomy.

CASE STUDY: BUSINESS INTEGRATION USING A FEDERATED BUSINESS MODEL

Lest we seem to assume an air of what Fowler calls "disinterested omnipotence" in the foreword to Eric Evans' book [6], let us say at the outset that the case presented here spanned some two years. For purposes of clarity and succinctness, we present things here in an order that we hope makes sense, which is not always in the order that things actually occurred, because in practice we stumbled around quite a bit, and not everything went right. What we think we learned, and what we hope to convey, is a way to approach requirements for EITA that is architectural, nonanecdotal, nonmysterious, and systematic.

This case study repeatedly references two techniques that helped us iteratively flesh out our business and IT architectures:

1. Pattern matching -- observing patterns in the problem space and correlating them with patterns in the solution space, and vice versa

2. "Ping-ponging" requirements -- using partial architectures in the problem space to create requirements for architecture in the solution space, and vice versa

As we progress through the case study, we'll check in periodically to show how we've applied these techniques.

Business Problem Context

A leading financial services company had struggled for years with what it perceived as a data integration problem. It was well understood that there were many data dependencies between applications across the company. Yet managing those dependencies turned out to be a huge problem. A common refrain across the company was, "I just can't get the data I need when I need it."

Solutions That Were Tried

Two main kinds of solutions had been put in place. One could summarize the organization's focus as attempting to answer the question, "How do we share data between systems?" The two main kinds of solutions were:

1. Point-to-point interfaces -- applications exchanged data via extract-transform-load (ETL) routines, file sharing, or direct database queries

2. Centralized databases -- applications wrote and read data directly to and from shared mainframe databases

Each of these solutions introduced a host of problems. The point-to-point interface solution proved to be very brittle for a number of reasons, including:

• Unknown source of truth -- since there were many applications that housed similar data, it was hard to figure out the best source of truth for a particular application's data needs.

• Mismatched data availability -- some applications required data from other applications according to different timing than was possible (e.g., a transactional system dependent on a batch-mode system).

• Semantic differences -- data in different application spaces was based on proprietary business semantics, resulting in unique data mapping for each interface that was time consuming to produce and often full of errors that only surfaced during integration testing or even in production.

• Disjoint development cycles -- coordinating changes in dependent applications was difficult because application teams worked to their own schedules as governed by their respective business owners.

• Technology platform -- each interface had to be constructed according to whatever technology each party happened to be using.

The mainframe databases also proved to be unreliable for a number of reasons, including:

• Unclear semantics -- there were no controls over "off-label" uses of data fields, implying that the meaning of mainframe data could not be guaranteed.

• Unknown source -- one couldn't tell who put what data in the mainframe database, making it difficult to determine if the data was reliable as a source of truth.

• Uncontrolled latency -- data was written to the mainframe database at the convenience of source applications, meaning that the data could be already stale by the time it showed up.

These approaches proved to be severely inadequate; as the company rapidly grew, the number of point-to-point system connections grew exponentially. A "simple" change to a database table in one application could produce unpredictable problems that would ripple across the organization. In one instance where several existing applications were to be replaced with a vendor package, it took an integration team 120 business days just to find the existing data dependencies, rework them to go against the new system, and then test them.

Because trustworthiness of data in the mainframe databases was suspect, many applications incorporated elaborate processes for checking mainframe data against other, presumably more trustworthy, data sources.

Note that the source of many of the problems was in determining what data to share. So the better question to be asking was "What data needs to be shared between systems?" rather than focusing on the technology of how to share that data.

An Enterprise Business Architecture Approach

There was no doubt that the company needed an enterprise architecture. In fact, a number of efforts to understand the requirements for EA had been tried. One effort sought to create an enterprise business use case model. Working its way across the company business area by business area, a small team of modelers spent well over a year interviewing business people and creating models, with the result being that it was about a third of the way done. This and other efforts all eventually ran out of steam for several reasons:

• There was no business prioritization, but the enterprise scope was huge, so the modeling efforts became huge.

• There was no sense of how the modeling outputs would be used, so there were no limits to what was modeled or to what level of detail.

• The models didn't comprehend the nature of the enterprise beyond being a collection of smaller pieces it contained.

This is where business architecture comes in. An important objective of architecture is to answer three key questions:

1. What are the important things?

2. What are the important connections between them?

3. How do they collectively serve a higher purpose?

So if our goal is an enterprise business architecture, we want to know:

1. What aspects of the business are important at the enterprise level?

2. What connections between them constitute enterprise behavior, as opposed to behavior of pieces of the enterprise?

3. How do they, the things thusly connected together, collectively serve the purpose of the enterprise, versus the purpose of some piece(s) of the enterprise?

Evaluating the Business Context

The company was engaged in the business of buying residential mortgage loans on the secondary market, securitizing the mortgages into mortgage-backed securities, and selling and servicing these securities on the open market.

The company was organized as a collection of business areas that, while interrelated, were operated relatively autonomously. They were interrelated in that they each owned some set of business processes that played a role in the larger enterprise value chain. Business areas essentially owned their own business processes but depended on other business areas for vital information in order to execute some of those processes. Each business area was thus a provider of business information for other business areas and conversely was a consumer of business information from other business areas. This exchange of information across business area boundaries was integral to the overall operations of the company. The very highest-level business processes of Acquire Mortgage Loans, Create Mortgage-Backed Securities, Sell Securities, and Service Securities could be modeled as sequences of smaller business processes across multiple business areas.

High-level enterprise business process modeling quickly showed that the business model was nonlinear: a given business process didn't necessarily occupy a single spot in a linear progression with identified predecessors and successors, and many business processes might run in parallel.

Business areas had a great deal of operational autonomy, including defining and implementing business processes, designing and implementing customized IT applications, and selecting and employing proprietary vendor software solutions. This company was very entrepreneurial and grew by acquisition; the autonomy of business areas was seen as one of the strengths of the overall business and thus wasn't about to change.

Within this context, it indeed turned out that the data issues discussed above tended to surface in cases where information flowed across business area boundaries. Inside the boundaries of business areas, where control over business processes, application development, and data was unified, solutions could more easily be worked out.

First-Order EBA

At this point, we could see a high-level pattern that captured some key things about how the company was organized and how it functioned:

• The company was composed of business areas.

• Business areas participated in an enterprise value chain.

• The business areas were autonomous in that they owned their own business processes.

• In order to participate in the enterprise value chain, sometimes business areas depended upon one another for information, reflecting circumstances under which the business areas were not autonomous.

Figure 3 offers a schematic view of this.

This view is clearly architectural in that it provides high-level answers to the three questions from above:

1. The important things are the company and the business areas within it.

2. The sharing of information between business areas constitutes enterprise behavior, whereas the business processes within business areas constitute the behavior of the pieces of the enterprise.

3. The business areas participate in the enterprise value chain by sharing information to execute enterprise-level business processes.

Pattern-Matching Checkpoint

At this point, we have observed a pattern in the business domain and have used it to document a high-level architecture for the problem space.

Matching the EBA to Reference Business Architectures

It turns out that our EBA was a fairly straightforward example of a federated business model. Admittedly, we found this out more by luck than by concerted research because, as noted earlier, there isn't exactly a book of reference business architectures out there to consult. In any case, this was a very important observation because it gave us a reference against which to compare our work.

Using the definition of the federated business model pattern from above, we can begin to identify important elements of this architecture from our case study. To make our model generic, and in keeping with our definition of "enterprise," we see that:

• The company is an enterprise.

• Business areas are organizations within the enterprise.

• Business areas exchange information, which are a type of resource.

Figure 4 shows the case-specific application of the federated business model architecture, where we have shown that it is the business processes within the enterprise and organizations that are exchanging resources.

Pattern-Matching Checkpoint

Based on high-level structural and behavioral patterns, we have matched our first-order business architecture (Figure 3) with a reference business architecture (Figure 2).

Key Business Requirements

With just this much analysis done, we could set down some key requirements for our particular business federation:

• Business processes can execute autonomously.

• Nonlinear business flow must be supported.

• Business processes can be added, can change, and can go away.

• Business areas can be added and can go away.

• How business processes are executed can differ.

High-Level EBA as Guidance for a High-Level EITA Solution

We now had a first-order architectural understanding of the problem domain, upon which we could base some high-level decisions regarding a solution IT architecture. The solution-level challenge was to enable business software systems to communicate and share information with one another according to the way that the business processes they implemented needed to communicate and share information. Exactly how those business processes were implemented remained within the autonomous purview of the respective business systems. But as long as the avenues of communication between business systems were unambiguous, consistent, trustworthy, and timely, the business would be well supported. This is the essence of technology alignment with the business model. In our case, that meant we needed a federated IT architecture to align with the federated business.

A Federated IT Architecture

Luckily for us, much work and writing had already been done on the federated information system (FIS) approach, in which an FIS "consists of a set of distinct and autonomous information system components, the participants of this federation. Participants in [the] first place operate independently, but have possibly given up some autonomy in order to participate in the federation" [5]. In particular, an FIS adds autonomy to the components of a heterogeneous information system, which is "a collection of information systems which differs in syntactical or logical aspects like hardware platform, data model or semantics."

This architecture provided an obvious first-order fit to our requirements. Certainly our participants, namely applications owned by business areas, were distinct and autonomous and were deployed with a variety of hardware platforms and data models. Indeed, autonomy and heterogeneity were interlinked. Autonomy, where component systems in the federation are designed and developed independent of one another, inevitably leads to heterogeneity, because autonomous system development naturally results in differing solutions.

Pattern-Matching Checkpoint and Requirements Ping-Ponging

Using our first-order business architecture, we laid out high-level requirements for the solution architecture, namely that the patterns of structure and interaction called out by the federated business model be matched in the solution architecture. Then we matched this to the FIS reference IT architecture.

Validating First-Order Solution Space Architecture with First-Order Problem Space Architecture

The following are some key specific dimensions of autonomy and heterogeneity as called out by the FIS approach, along with descriptions of how they mapped to our business requirements.

• Design autonomy -- component systems may be designed independently in terms of data model, naming concepts, and so on, and the design of a component system may be changed at any time.

  This would allow business areas to continue to build or purchase solutions as best fit their business need.

• Communication autonomy -- a component system can independently decide which other component systems it will communicate with. Component systems may enter or leave the federation at any time.

  This would allow component systems to be replaced without affecting the overall enterprise. In particular, it would facilitate integrating new business functions or business acquisitions, which bring with them newly developed or acquired legacy systems. This would also support nonlinear business process flow.

• Execution autonomy -- component systems decide independently when to schedule and execute incoming requests, within the constraints of SLAs.

  Already we had a mixture of transactional and batch-mode systems. Execution autonomy would continue to allow component systems to execute according to the dictates of the local business processes they were designed to support.

• Syntactical and data model heterogeneity -- syntactical heterogeneity refers to technical differences in hardware platforms, operating systems, and access methods. Data model heterogeneity recognizes differences in how to organize data (e.g., hierarchically, using relational calculus, using an object metaphor).

  These dimensions of heterogeneity would support the existing, and inevitably continuing, mix of technology that results both from business area autonomy and from the possibility of mergers and acquisitions.

• Logical heterogeneity -- this recognizes differences in how the same business term might be defined, or how different terms might refer to the same concept, and also acknowledges that similar information may be encoded differently.

  A mere handful of interviews with business subject matter experts revealed that terminology was far from standard across the enterprise. Thus this dimension of heterogeneity would allow business areas to continue to define and encode business terms in a manner that best suited their perspective.

• Structural heterogeneity -- component systems may physically structure data differently, even if they share semantics and data model.

  Already, database administrators in different business areas designed their physical data models according to local business need; this could thus continue to be supported.

Requirements Ping-Ponging Checkpoint

Here we've explored the autonomy and heterogeneity characteristics of the solution space architecture and validated that it supports key business requirements.

Adapting IT Architecture to the Business Architecture

The basic structure of FIS, shown in Figure 5, calls out a federation layer, which offers users and applications a uniform way of accessing data stored in heterogeneous data sources. This is implemented by some specific interoperation strategy (e.g., a federated schema or a uniform query language). The various data sources generally are integrated into the infrastructure using wrappers to resolve some technical differences.

Within the realm of FIS architecture, there are many permutations that support the above dimensions of autonomy and heterogeneity to varying degrees. In particular, the nature of the interoperation strategy in the federation layer has everything to do with how much autonomy and heterogeneity among component systems the federation will tolerate.

The federation layer is where interactions between parties to the federation take place. In order to design an appropriate interoperation strategy for our federation layer, we needed guidance from the business architecture as to the nature of those interactions: We needed to know more about the "lines between the dots." What exactly constituted our federation? What information was exchanged by whom, and why and when?

Requirements Ping-Ponging Checkpoint

Having established a proposed solution space architecture, we've used its core structure to call out requirements for the problem space. That is, based on the requirement for an interoperation strategy in our solution space architecture, we've created the requirement to define a corollary interoperation strategy in the problem space architecture.

This is a direct application of modeling for a purpose: we've got a target solution in mind, which tells us what elements to go look for on the problem side.

A Business-Level Interoperation Strategy

Turning again to our high-level enterprise business architecture, we looked specifically at the interactions between parties to our federation, and we noted a couple of things:

• Enterprise-level business processes were carried out by the interactions between business area-level business processes; that is, an enterprise business process consisted of some flow across business processes owned by business areas.

• Business area-level business processes interacted by exchanging information.

A closer look at the nature of the information exchanged across business area boundaries revealed that this information was not used to coordinate business processes in a workflow manner. Rather, the information being exchanged described, in object-oriented parlance, business entities. This was not surprising, given the nonlinear enterprise business flow and the fact that the business processes that were exchanging information remained otherwise independent of one another.

All of this gave us the notion that we were faced with a business integration problem rather than a data integration problem. That is, if the enterprise behavior consists of the behavior of the integrated whole, then what set the enterprise apart from the mere collection of its parts was the way in which those parts interoperate.

We thus proposed that the sets of information being exchanged between business processes were not the subject of the problem domain. Rather, the problem domain was the set of circumstances that caused business processes to require information from outside their own business area. The information thus described those circumstances.

So the question that started out as "How do we share data between systems?" became "What happens in the business that is important outside of the business area that it happened in?" Restated another way, "What are the enterprise-important business events?" This provided the lens through which we looked at how the interoperation strategy of our federation needed to work.

Event-Based Business Model

We consulted the OMG's UML Profile for Enterprise Distributed Object Computing (EDOC) [11], which among other things lays out a model for event-driven business computing. The preamble to this describes the nature of an event-based business model:

An event based business model is driven by business events. Whenever a business event happens anywhere in the enterprise, some person or thing, somewhere, reacts to it by taking some action. Business rules determine what event leads to what action. Usually the action is a business activity that changes the state of one or more business entities. Every state change to an Entity constitutes a new business event, to which, in turn, some other person or thing, somewhere else, reacts by taking some action. [11]

Our notion of business processes as producers and consumers of information about business entities fit this model closely:

• Business processes "produced" information about business entities by acting upon them, causing business entity state changes, and thus business events, to happen.

• Business processes consumed information produced by other business processes, by consuming information about business entity state changes that were caused by other business processes.

Thus we settled on an event-based business model for our interoperation strategy on the business side. Figure 6 shows our EBA updated to reflect this new understanding.

We've chosen to model business events as an association class between business entities and their states, with the understanding that a business event represents the occurrence of a specific state change of a business entity.

Pattern-Matching and Requirements Ping-Ponging Checkpoint

The need for an interoperation strategy in the federation layer of our solution architecture required us to define an interoperation strategy in the problem space architecture. Looking specifically at how interactions took place between federated business areas, we concluded that business events best described the content and context of these interactions. Then we matched this pattern of interaction to a reference business architecture, the event-based business model.

Event-Driven Business Computing as a Paradigm for Federated Architecture

On the problem side, we still had to answer our question, "What are the enterprise-important business events?" Before we address that question here, let's explore how we reconciled the concept of an event-based business model with our proposed FIS solution architecture.

If an event-based business model were to be supported by an FIS architecture, we had to figure out whether and how an event paradigm would work as an interoperation strategy in the federation layer.

The EDOC document describes event-driven business computing, which applies two loosely coupled architectures to enable an event-based business model:

1. Event-driven process architecture

2. Publish and subscribe information distribution architecture

Figure 7 is a synthesized schematic picture of an event-based business model in the context of these two architectures.

As seen in the figure, Business Process A executes an activity (some part of the business process) that acts upon a business entity by invoking an action. This causes a state change, which is published as an event notice. Business Process B, having subscribed to that particular event, receives a notice that the event (i.e., the state change) has occurred. Based on its own rules (condition), Business Process B reacts to the notice by executing some activity.

In all of this, Business Processes A and B are independent from each other, indeed anonymous to one another. Their only interaction is based on the causing of, and interest in, the same business event.

The notification-condition-activity cycle within the business processes represents the event-driven process architecture, and the action-state change-event cycle in the business entities represents the publish-and-subscribe information distribution architecture.

These architectures clearly supported our key business requirements. The publish-and-subscribe information distribution architecture supported autonomous business areas by allowing business processes to exchange needed information while remaining autonomous. The event-driven process architecture supported our nonlinear business flow: rather than being sequenced in a traditional workflow manner, autonomous business processes could perform their responsibilities in response to loosely coupled notifications. The loosely coupled nature of these architectures also ensured that business processes and business areas could come and go without affecting the overall enterprise.

We did make one modification to the event-driven process architecture; because our business areas, and the business processes they controlled, were autonomous, the federation layer could not encompass the mechanism for how business processes reacted to notifications. But we did preserve the ability of business processes to receive loosely coupled notifications and to act upon business entities.

A Business Integration Metamodel

With this modification we now had, from a business perspective, a viable paradigm for the interoperation strategy of our federation layer. We were able to derive a succinct metamodel for how to integrate the business, as shown in Figure 8.

Notice that Figure 7 describes the basic concepts of the interoperation but leaves many questions open, for example: How many business activities does a process have? Do activities always invoke actions? The formal model of Figure 8 provides a precise, unambiguous definition (specification) of the interactions. This model was used by the different autonomous business units to define the events, information, activities, actions, and so on, so that all groups produced consistent results (i.e., interoperability). In architecture, it is common to provide both a "conceptual model" and a formal model of the solution.

Pattern-Matching and Requirements Ping-Ponging Checkpoint

Having settled on a business event model as our interoperation strategy on the business side, we had to come up with an architecture for how an event-based interoperation strategy could work in the federation layer of our solution space architecture. This led us to adopt two interrelated architectures:

1. Event-driven process architecture

2. Publish-and-subscribe information distribution architecture

We then validated these architectures against our business requirements and modified the event-driven process architecture to match the level of business process autonomy that business areas already had and would continue to have.

Filling in the Puzzle

At this point, there were two major things left to do. In the problem space we had to come up with the list of business events, and in the solution space we had to figure out how to design the event-driven federation layer so that it supported the dimensions of autonomy and heterogeneity called out by the FIS architecture.

Analyzing Business Events

What were the enterprise-important business events? Of course, this question had to be answered by business people; it had nothing at all to do with IT.

The business integration metamodel served to guide business analysis. In keeping with "modeling for a purpose," this metamodel outlined what was and was not important to our business analysis effort.

For example, the internal details of a business process were not important other than noting when it updated a business entity. One could break down a business process into a flow model of activities, say using a UML activity diagram. Only when a business activity invoked some action on a business entity would we need to have anything but the most cursory understanding of that business activity. And the only thing we'd need to understand was what action(s) it was taking on which business entity or entities. This meant that the whole litany of detail that usually comprises business process modeling was largely irrelevant here.

Based on the metamodel, business analysts needed to determine exactly what were the "important" business entities, what were the "important" state changes to them, and thus what constituted "important" business events, and what information properly described all of the above?

Because the ultimate goal was to get the enterprise federation to work, a cross-functional group of business experts from across the enterprise was put together to tackle these questions. One of the first things this group did was to learn some business modeling techniques, using a very small subset of UML. Not surprisingly, this group was at first very resistant to learning what it considered to be "technical" modeling. The group just wanted to describe the business (which it claimed to have a shared understanding of) and have IT modeling experts "write it down" for them. However, literally the first time two business experts approached the whiteboard to model a business entity, they disagreed on a definition for it. So the issues they grappled with went all the way down to establishing and agreeing upon common business terminology around which they could then formulate a clear picture of how to integrate the business.

Over time, these business people became quite competent at clearly and precisely modeling the business problem domain. They discovered that it was not difficult to learn how to model, that it was much more effective to do it themselves than to have to rely on IT, and that the models produced contained much richer and more precise information that eliminated ambiguity and disagreements. They produced a set of business integration models, consisting of:

• Business process model -- use case diagrams for overall context; activity diagrams to outline business process details

• Business object model -- class diagrams of business entities, their relationships, important attributes, and actions that could be invoked to change their state; state transition diagrams to show the enterprise lifecycle of business entities, including events published as a result of state changes

• Business event model -- business event descriptions; special-purpose dependency diagrams to show consumers of business events

This business integration model consolidated all of the relevant business requirements for integrating the federated business.

This process and its resulting models were an example of addressing complexity at its source. The struggle to establish an enterprise business lingua franca was properly addressed by business experts, rather than being left to system integrators and data analysts. The scope and nature of business process interdependency were explored, documented, and prioritized by those who lived by those processes day to day, instead of expecting IT people to somehow magically figure it all out.

Requirements Ping-Ponging Checkpoint

The business integration metamodel that guided business analysis was derived from the requirements of the core architecture for the solution-side federation layer. Here again we have an example of modeling for a purpose: the needs of the solution point to what is important to understand and model in the business.

FIS Requirements and Design

The last major piece was to flesh out the FIS architecture to address the question of how heterogeneous systems could:

• Produce business events, where an autonomous application shared with the enterprise any changes it made to "enterprise" data

• Consume business events, where an autonomous application received information about changes that other applications had made to enterprise data.

This entailed designing an event-driven federation layer that supported the dimensions of autonomy and heterogeneity called out by the FIS architecture.

Having converged on an event-driven computing paradigm, and given the needed dimensions of autonomy and heterogeneity, it was not difficult for us to settle on a message bus pattern for our federation layer middleware. Since much has been written about these kinds of solutions, we won't go into detail here but instead will focus on key elements and their correlation to our requirements.

Some key elements of this architecture were:

• Publish-subscribe pattern for a common communication infrastructure -- this decoupled applications in the dimensions of design, execution, and communication autonomy.

• Adapters for connecting autonomous applications to the enterprise middleware -- this supported logical and syntactical heterogeneity by allowing applications to translate to and from a standard set of messages, as well as structural and data model heterogeneity by entirely isolating application-specific data storage issues from the enterprise.

• A canonical data model to define common business semantics -- derived from the business integration model, this supported logical heterogeneity by providing standard business semantics upon which all messages were based.

• A common command structure to define the set of enterprise-level communications -- this consisted of a catalog of standard command messages for executing actions on business entities and event messages for describing the occurrence of business events.

Clearly we had succeeded in supporting the important dimensions of autonomy and heterogeneity for applications. And we had spelled out the rules of engagement for participating in the enterprise, setting forth exactly "what has to be the same so that the rest can be different." ²

A Materialized Enterprise Business Object Model

Our business integration metamodel defined a set of shared enterprise business entities upon which business processes could act. However, at the implementation level, each autonomous application potentially had its own copy of "enterprise data" representing these shared entities. So the point of our enterprise IT architecture was to ensure that autonomous applications could keep their copies of shared business entities up to date, based on activity undertaken by other applications.

Our nonlinear business flow meant that enterprise data integrity could not be guaranteed by enforcing business process sequencing. Execution autonomy meant that we couldn't rely on the timing of individual applications updating data. Thus allowing applications to simply publish enterprise data changes wasn't good enough; we had to have a synchronization point. This meant we needed a material, not virtual, "enterprise copy" of each shared business entity, which would represent the "true state" of that business entity at any point in time.

This need was fulfilled by a set of business object services running against an operational data store. Each business object service represented the behavior and state of a particular business entity. A business object service provided interfaces exposing operations corresponding to the set of actions that could be invoked on its business entity. The execution of these operations included executing the business entity state machine and publishing the appropriate event notices.

So the catalog of standard command messages for executing actions on business entities really entailed action requests; an application, having made a change to enterprise data would send a message requesting that the "enterprise copy" of that data be similarly updated. One of the consequences was that an action request could be denied because of a state machine violation. In this case, it would be incumbent upon the application to handle that exception within its own domain; other applications in the federation would not receive notice of the attempted data change.

GENERALIZING THE EA PROCESS

Our case study illuminated a process that we think can be applied in a general way to the task of defining EITA such that it clearly aligns with and supports the needs of the business enterprise as defined by the EBA.

The process starts with evaluating the enterprise business context and driving out a first-order EBA. The succeeding steps are an iterative process that alternates between using the EBA to create requirements for further EITA development and using the EITA to create the need for further enterprise business requirements.

Figure 9 illustrates this process as a UML activity diagram.

Throughout the process, we have applied the architectural principles that were laid out earlier, specifically:

• Finding important elements -- identifying the important architectural elements at a particular level of abstraction, identifying the important connections between them, and delineating how they collectively together serve a higher purpose.

• Modeling for a purpose -- having an end goal or "story" for how you'll use the model later in the process will ensure that you're addressing key issues and not wasting your time.

• EBA as EITA requirements -- ensuring EITA meets business requirements just like any business application, and those requirements should describe the architecture of the business enterprise.

• Architectural patterns -- looking for patterns helps us focus on the salient distinguishing characteristics of business architecture and helps us match business architecture to technology architecture.

• Addressing complexity where it lives -- realizing that complexity can't be avoided, thus complexity should be modeled and addressed at its source rather than some downstream solution space.

Let's review how the process was applied to the case study.

Establish Enterprise Problem Domain Context

This is an up-front process step whose goal is to characterize the nature of the business enterprise, specifically distinguishing it from the parts of the enterprise and from the simple collection of its parts. The focus is on the nature of interrelationships between the parts and how those interrelationships constitute the unique enterprise.

Case Study Example

Our analysis found an enterprise value chain that was implemented by a collection of autonomous business areas. Enterprise-level business processes were nonlinear sequences of local business processes, in which these local business processes shared certain information across business area boundaries.

Update EBA with New/Changed Elements

The first time through the process, this is an up-front step wherein you capture a first-order picture of the important components of the business enterprise. Look for enterprise business patterns that can help point to reference business architectures.

Case Study Example

We referenced the federated business model to create our first-order EBA. Lacking an expression of the federated business model as a business architecture, we captured it as consisting of an enterprise, relatively autonomous organizations in the enterprise, and resources exchanged between organizations. Applying this to our business problem, the salient point was that information constituted the resources being exchanged and that it was local-level business processes that shared the information across business area boundaries.

Analyze EBA-Driven Need for EITA Changes

This step and all of the remaining steps occur iteratively, as shown in Figure 9.

This step looks at the updated EBA to determine whether new or changed elements are required in the EITA. Remember, an EBA sets forth business requirements that are enterprise in focus and architectural in nature. Such requirements are clearly aimed at an enterprise architectural solution. This is at the heart of business-IT alignment at the enterprise level.

It can be useful to look at any architectural patterns expressed in the EBA to help point toward existing reference EITA architectures or patterns.

Case Study Example

Using the pattern of relatively autonomous business areas collaborating within an enterprise, we found a close fit with the FIS reference architecture.

Update EITA with New/Changed Elements

Having analyzed the EBA requirements and having considered reference solution architectures, update the EITA with new and/or changed components.

Case Study Example

In adopting the FIS reference architecture, we introduced applications, data stores, wrappers, and a federation layer into our EITA.

Validate EITA Against Key Business Requirements

Having updated the EITA, validate whether and how its key characteristics will support key business requirements.

Case Study Example

We matched up the FIS dimensions of autonomy and heterogeneity to the requirements of our autonomous business areas to define and execute their business processes as well as to make their own technology choices.

Analyze EITA-Driven Need for Further Requirements

Having updated the EITA, you may now need further business requirements. Examining the key components of your EITA can point you to the kinds of requirements you'll need from the business side. Questions to ask include:

• What key mechanisms characterize the important EITA components?

• How do these mechanisms relate to the problem domain?

• What do you need to understand in the problem domain in order to make design decisions regarding these mechanisms?

Case Study Example

The FIS reference architecture called out a federation layer that implements the interoperation strategy by which federated systems interrelate. This pointed out the need to understand how business processes interrelated and to architect a corresponding business process interoperation strategy

Analyze Enterprise Business Requirements

The evolving EITA may produce the demand for changes to the EBA. Fleshing out an EITA solution inevitably points to the need for greater understanding of the problem domain. This then guides problem domain analysis such that it is specifically targeted at defining requirements that "have a home" in the solution domain. Here again, considering business patterns and/or reference business architectures can be useful.

Case Study Example

Guided by the need to define a business process interoperation strategy, we analyzed how business processes interrelated and concluded that business events were the key metaphor. Matching this with a reference architecture, we adopted the event-based business model as our business process interoperation strategy.

Update EBA with New/Changed Elements

Having performed business requirements analysis guided by the needs of the solution architecture, and having considered reference business architectures, update the EBA with new and/or changed components.

Case Study Example

After adopting the event-based business model as our overall paradigm, we updated our EBA model to reflect that the information "produced" and "consumed" by business processes described business events.

And So We've Come Full Circle

This summary has reviewed a single "round-trip" through the process. Although our case study went through another iteration, we think the above is sufficient to illustrate the overall ideas of the process.

CONCLUSION

In this report, we've looked beyond the cliche of "aligning IT with the business" to explore how to discover, model, and validate robust business requirements for enterprise IT architecture.

At the heart of our thesis is the necessity of enterprise business architecture, both as a set of artifacts and as a discipline. An architectural approach to enterprise business requirements makes it possible to formulate effective enterprise architectures that provide the greatest value to the enterprise they seek to serve.

We've laid out a process by which enterprise business architecture and enterprise IT architecture can be developed in parallel, each iteratively leveraging and validating against the other in an architectural coevolution.

Addressing EA Failure Modes

The process we've explored has the potential to help EA efforts avoid some common pitfalls. Chief among them are the lack of enterprise-level business requirements and the tendency to "model the business" without having a clear picture of how the requirements will be used.

EITA needs business requirements as m