In this chapter, we dig deeper into the question of what enterprise architects actually do to manage an enterprise’s architecture. What duties belong to their role and make up their profession? What kinds of activities characterize their daily work, and what are the established best practices to perform those duties?

Because of the many facets of EA, any compilation of EA activities will probably be incomplete, but the selection we lay out in this chapter lists the situations we most frequently encounter in both practice and literature. The activities we find most characteristic and prevalent are shown in Table 3-1.

Table 3-1 Core Activities of Enterprise Architecture Management

The emphasis on activities can be different in each firm; an activity that gets the most attention in one firm might be almost neglected in another. Therefore, we do not make an attempt to prioritize activities by importance or effort involved. Neither are we interested in putting them into a sequential order; this is achieved by frameworks such as the TOGAF^TM Architecture Development Method, which we’ll take a look at in the next chapter.

Instead, the two major goals here are drawing a realistic picture of the kind of work that enterprise architects are entangled in and describing some of the established practices to succeed. But we’ll constrain ourselves here to contemporary best practices, meaning approaches you can find out there in the field or in the relevant publications. They’re not our invention, and in the following sections we describe those practices that are, in our own judgment, most well known and convincing.

In contrast, Part II of the book (Chapters 6 through 8) is dedicated to improvements of the state of the art. We will frequently refer to EA-1 to EA-8 (as shown in Table 3-1) to assess in which activities the improvements can do some good and how they change the current way of working.

But for now we’ll stick to the current practice and hope that the newcomer to the subject gets a tangible view of EA, whereas the old hands may enjoy a quick recap, hopefully learning about one or two items they didn’t know about before.

Defining the IT strategy (EA-1)

Half of the activities of EA are strategic by nature. Evolving the IT landscape, for example, entails drawing the future information system landscape, which certainly gives a strategic direction. But EA-1, as we shall see, sets up the principles guiding all subsequent strategic decisions and thus is the root and point of departure for strategy.

Defining the IT strategy positions IT in the enterprise environment and future direction and defines how IT can be better utilized to attain business goals. This process consists of three steps:

1. Defining the goals to be pursued over the time span covered by the strategy

2. Stipulating the rules that dictate how these goals are to be reached

3. Identifying the initiatives that move the enterprise’s IT toward the goals

In this section, we’ll walk through these steps one by one and explain the challenges and approaches involved in each of them.

Defining the goals

Let’s first take a look at an example of a typical business goal: The automotive industry has become highly volatile in the past few years. Manufacturing plants are shooting up like mushrooms in emerging markets, and the car companies force their suppliers to keep up with this rapid pace. As a manufacturer of shock absorbers, for instance, you must be able to build up a new supply plant sufficiently fast wherever in the world your major customer decides to build cars; otherwise, you’re out. The ambitious goal your business management derives from this challenge is:

We must be able to ramp up a plant in half a year in any geographic region, and we want to reach this capability in one year.

This is a business goal, and quite a good one. It scores quite high when benchmarked against the acronym SMART. This quality seal gathers the features a useful goal should have: Specific, Measurable, Actionable, Relevant, and Time-bound. The previously stated business goal could be a trifle more specific about the geographic regions and under what conditions a plant is considered “ramped up.” But it at least states a metric and the ramp-up time and nails down the time horizon of one year (it is time-bound). The addressees probably recognize it as relevant and roughly know the first steps to act on it (it is actionable).

But in practice, one often finds that goals lack some or all of the SMART qualities. Mack and Frey (2002) list some caricatures of goals that are, for instance, absurdly unspecific: “Increase our market share,” “Make our products more attractive,” “Keep existing customers and acquire new ones.” It indeed is close to impossible to derive guidance from such goals—in particular if they just are a small excerpt of a long CEO Christmas list. Platitudes like this don’t pass the “Dilbert Test” illustrated in Figure 3-1: State the opposite, and watch whether something absurd takes form.

Figure 3-1 The “Dilbert Test” for platitude goals.

The Christmas list, meaning the obstacle of an unfocused or even contradictory set of goals, can only be mitigated by urging the board of business managers to decide for a handful of them. If the business leaders decide to drop “Make our products more attractive” but not “Keep existing customers and acquire new ones,” we at least have a clue where the business is heading. Strategic initiatives consequentially should invest in marketing and CRM rather than in improving the product development or manufacturing chain. In most cases, however, the issue won’t be an “either/or.” Instead, prioritization of goals will be required, a step that inherently belongs to defining goals. A choice or ranking implies a mandate to act on, and the maxim process we shall describe a little later can help in pushing a business board to make it.

Several flavors of the term goal are in use. Some talk about objectives, some about requirements, and others swear by formulating visions. These flavors have their point, but in terms of the bottom line it is all about agreeing on what is wanted, how eagerly it is wanted, and maybe who wants it. There’s no need to be overly subtle about it.

Stipulating the rules

There’s a broad consensus that defining the IT strategy is an exercise that cannot be achieved without an intense collaboration between business and IT. Broadbent and Kitzis (2005) regard the involvement of senior business executives in the definition of the IT strategy as the crucial factor in turning IT from a cost-generating infrastructure to a business enabler. Nevertheless, in practice it is difficult to get business executives on board.

A proven approach to tackling this obstacle is the so-called management by maxims process conceptualized by Broadbent and Weill (1997). The process is far from being rocket science: It boils down to gathering the senior business and IT representatives for an intense one-day brainstorming workshop. The pain of business executives to devote some time to IT is thereby kept at a minimum. To make the most of such a day, there must be three topics on the agenda:

• Definition of the business maxims

• Derivation of IT maxims out of the business maxims

• Agreement on the extent of shared services and infrastructure support

For the day to be a success, the topics must previously be prepared by some assistants; the enterprise architects typically belong to this group. On the day itself, it might be just the chief enterprise architect who is invited to the illustrious workshop.

The first two agenda items are about maxims. Broadbent and Kitzis (2005) define a maxim as a “statement that specifies a practical course of conduct.” They recommend formulating not more than six business maxims that “[…] need to be concise, compelling, concrete, easily communicated, and readily understood as statements that people throughout the entire organization can use as guidelines for making decisions and taking actions.” Here are two examples of good business maxims taken from their book (2005, pp. 84, 91):

• All sales employees are decision makers about taking new policies and cross-selling.

• Maximize independence in local operations with a minimum of mandates.

Deducing IT maxims from such business maxims is the second topic on the agenda. There can be more IT maxims than business maxims, but the catalogue should still be crisp enough to be remembered by members of the organization in their daily decisions. The two examples stated previously, for example, could give rise to the following IT maxims:

• All sales employees, wherever they are, must have access to contract and customer data.

• Business units can determine the most suitable applications for their business, provided they comply with a minimum set of standards set throughout the enterprise.

The last item on the agenda is to get an idea of the enterprise’s need for shared services and infrastructure. The deeper rationale for this exercise is to position the firm (or maybe even individual business units) in what Jeanne W. Ross from the MIT Center for Information System Research calls an operating model. Ross (2005) distinguishes four main categories of operating models, as shown in Figure 3-2.

Figure 3-2 Four operating models (Ross, 2005, used with kind permission)

Technical people, especially technology-focused architects, have a bias for standardization and integration and tend to believe that these most naturally belong to the canonical goals of each enterprise. But it is not a matter of maturity in which of the quadrants of the Ross model an enterprise ends up; it depends on the business outlook, the competitive strategy, and the enterprise governance. Let’s take a brief look at each of these parameters.

Broadbent and Kitzis (2005) distinguish three fundamental business outlooks, namely:

• Fighting for survival. Budget cuts, layoffs, and cancellation of initiatives characterize this outlook. The emphasis is on cost reduction.

• Maintaining competitiveness. The enterprise is parsimoniously balanced between cost savings and investments in initiatives. Budgets are flat, and new initiatives must be thoroughly justified.

• Breaking away. These are the happy days for new initiatives. Budgets are generous, and the challenge for IT is in keeping up with the growth, or even better, driving it.

The second parameter following the business outlook that influences the need for standardization and integration is the competitive strategy. The economist Michael Porter (1998) describes three generic strategies that, on a rough scale, classify all approaches to competition. These are:

• Cost efficiency. Offering a better price is the main competitive advantage. The emphasis is on operational excellence to keep costs low.

• Differentiation. The enterprise tries to combat competitors by better products, quality, or customer care. The emphasis is on product leadership or customer intimacy.

• Focus strategies. The enterprise gains advantages from occupying market niches.

Even in the generic terms sketched here, it becomes evident that an enterprise architect who is much in favor of standardization and integration can do harm to an enterprise that is breaking away and strives for differentiation by developing the most innovative products on the market. While business is demanding a rapid positioning of new IT applications and services, the EA hits the breaks by imposing standardization and integration compliancy on the development teams.

Enterprise governance is of equal importance as the previous two parameters. Weill and Ross (2004) define governance as a body of meta-regulations for management, stipulating the following issues:

1. What kind of decisions must be taken

2. Who is accountable for making these decisions

3. How decisions are made and eventually monitored

One core question decided by governance is how much autonomy is granted to business units or geographical regions. In case this autonomy is high, would a quest for high IT integration and standardization not be like fighting windmills?

Therefore, the enterprise architect must be aware of the business outlook, the competitive strategy, and the enterprise governance and must use them as landmarks in decision making. The maxim process provides a useful opportunity to call for information about these parameters.

A remarkable feature of the maxim process is that it is about abstract rules only. Broadbent and Weill (1997) coined the term management by maxims for a kind of strategy definition founded on abstract decision rules. This approach actually does away with a popular misunderstanding of what a strategy actually is. Elementary game theory defines a player’s strategy as a “complete plan of action for whatever situation might arise; a plan that fully determines the player’s behavior at any stage of the game, for every possible history of play up to that stage” (Wikipedia “Strategy,” 2011). The player becomes an executor of an algorithm in this conception, as visualized in Figure 3-3.

Figure 3-3 Strategy as algorithm: A popular misconception.

But for complex games like chess, there is no algorithmic strategy that guarantees a win. Who would expect that there is an algorithmic plan of action that guarantees a successful transformation of the enterprise’s IT, a plan ensuring that all business goals are met? This algorithmic concept of a strategy has its limitations.

Complex systems cannot be managed at an object level, only at a meta level. This will be one of our insights we discuss in Chapter 6, “Foundation of Collaborative EA,” where we reflect on the key implications of complexity. Management at a meta level basically means management by maxims.

Existing frameworks for defining an IT strategy widely acknowledge this constraint. The TOGAF framework, for example, uses the term principle instead of maxim. But principles are defined as “general rules and guidelines […] that inform and support the way in which an organization sets about fulfilling its mission” (The Open Group, 2009, p. 265). Thus, principle can in practice be regarded as a synonym for maxim. Principles are identified in the Preliminary and Architecture Vision phases of the TOGAF^TM ADM, and they form a foundation for the subsequent architecture definition endeavor.

It is a good practice to accompany the bare statement of a principle by a rationale, a set of implications the principle might have, and possibly further auxiliaries such as metrics or the application context. This helps the decider and is recommended by TOGAF as well as by Weill and Ross (2004).

The Gartner Grid

Gartner Research has elaborated another methodology for formulating IT strategies in a series of papers published during the years 2002 and 2003. The definition of strategy in these papers is very concise (Mack and Frey, 2002):

A strategy takes a vision or objective and bounds the options for attaining it.

The approach to “bounding the options” actually is spelling out abstract decision rules and therefore is yet another instance of management by maxims. The most often cited concept from Gartner’s papers is the two-dimensional grid shown in Table 3-2. This grid can be used to check the completeness of IT strategies.

Table 3-2 Business Strategy Elements Mapped to IT Strategy

On one hand, this grid ensures that all aspects of the IT strategy that may require a decision further down the road are guided by rules. On the other, it lists all inputs from the business strategy that can have an impact on IT and therefore must not be neglected.

The seven inputs from the business strategy are spelled out as follows:

• Geographic. This is about the expansion and national/international distribution of the enterprise.

• Governance. Who makes decisions, and how are they made? Are the business units or geographic regions relatively autonomous, or is there a strong central authority?

• Future. This concerns how far the time horizon of business plans is. They can be long-term, midterm, or even bound only to what has to be done next.

• Legacy IT. Is there a will to make drastic changes, or is the attitude conservative and committed to the current way of operation?

• Virtual. This is about the involvement and integration of service providers and other partners. What capabilities and processes are kept in-house, and which are handed over to partners?

• Customer. How strongly does the enterprise want to engage its customers?

• Funding. Who is paying and how much? How are projects funded, and what are the criteria for granting budgets?

These inputs must be taken into account, according to Gartner. If they are not available right away, the enterprise architect must seek answers and hold the business side accountable for giving them.

The business imperatives are then mapped to five components of the IT strategy, which can briefly be explained as follows:

• Infrastructure. This is the technology component, comprised of hardware, software, and network elements.

• Service. This concerns the services provided by the IT department to the enterprise, to partners, and to customers.

• Applications. This is about the portfolio of applications, their business functions, and the processes and organizations it supports.

• Integration. All means making the enterprise act as a single unit are subsumed under this component.

• Sourcing. This component addresses the source of all the people who perform the IT-related strategic work. In particular it sets rules for selecting internal employees or external service providers.

Now, how can we use the Gartner grid in practice? Let’s take the example of an automotive supplier and the goal we discussed earlier:

We must be able to ramp up a plant in half a year in any geographic region, and we want to reach this capability in one year.

This requirement can be seen as one of the inputs in Gartner’s Geographic row. But what does it imply for the different columns of the IT strategy? Here is a walk-through that should sketch the idea:

• Infrastructure. The IT organization decides to go for highly standardized technology stacks that can rapidly be replicated to new sites. The rule is to prefer out-of-the-box solutions over custom implementations.

• Service. The guideline is to rely as much as possible on onsite services but to work according to the standards established in other parts of the world. Services are to be provided in the local language.

• Applications. The principle is to utilize the standard applications and global templates of business processes. Customization must be justified by strong reasons—for instance, country-specific legal constraints.

• Integration. The integration is to be kept to a minimum. Integration costs grow over-proportionally with the number of sites, and a tight integration can slow the implementation.

• Sourcing. The work is done by onsite forces. External suppliers are preferred in order to keep latencies for training and education at a minimum.

In practice, the mapping rarely is straightforward and without logical conflicts. A good governance of strategic planning should not leave the IT side alone with business requirements that are impossible to accomplish. Instead, there must be feedback loops allowing for a reconsideration or reprioritization of business maxims.

Identifying the initiatives

Just envisioning the goals and stating the rules does not get things going. One also has to identify the strategic initiatives people should start working on. We intentionally use the term initiative because the plan of action is usually yet too coarse to speak of well-scoped projects. At this granularity, it is not about a proper project portfolio management: The how is widely unclear, there’s no target architecture in place, and all we have is intentions to start with. A typical scenario would be an imaginary car manufacturer, Cars4Us, which has committed to the goal of keeping existing customers.¹ A high-level business maxim aiming at this goal could be:

We make the customer perceive us as a helpful companion, and we maximize the number of services and contact points accordingly.

The different business units of Cars4Us examine this maxim and come up with initiatives as to how to put this into practice. Customer care concludes they should point the customer to all service incidents and technical checkups in advance. Therefore, they take up a business initiative that models the whole life cycle of a car, with all probable events and corresponding interactions (car care, repairs, new purchase, etc.) with the customer. The IT initiative derived from it implements this process in the customer relationship management (CRM) system and automates such things as sending notification mailings about upcoming technical checkups.

Marketing, on the other hand, intends to extend the services beyond the narrow scope of car caretaking. They kick off an IT initiative centered on mobile applications in order to explore what kind of helpful gadgets could be offered on a smartphone. The range is wide: racing games with Cars4Us models, augmented reality manuals for the car, or apps alerting the user to events such as concerts or football games close by. The initiative is complemented by an investment into customer analytics. Cars4Us wants to learn about the customer and her wishes from the mobile interactions.

This example illustrates that there’s no way to systematically deduce the right initiatives. There’s not even a framework for guidance. One is left to one’s own creativity and a thorough understanding of the enterprise and the way the business is run.

The initiatives usually do not directly lead to implementation projects. The latter are rather pursued by pre-projects detailing the requirements and target architecture to a level that allows for proper project planning of effort, business value, and risks involved.

The role of an enterprise architect

Enterprise architects are typically not accountable for the enterprise’s IT strategy. It is the CIO who signs off on it and has to answer for it. Nevertheless, enterprise architects usually participate in strategic boards and meetings, prepare decisions, or elaborate drafts coming out of such meetings. There can be parts of the IT strategy on which enterprise architects have little to say—for instance, in defining service-desk policies. But even if they are not primary speakers in these parts, they are at least informed or consulted. Hence EA is deeply involved in shaping the enterprise’s IT strategy.

Defining the IT strategy is a hot spot with regard to interpersonal issues, since it is on the borderline between business and IT and critically depends on the collaboration between the two. In a sense it is the stage for a culture clash, a meeting point of businesspeople on one side and IT folks with roots in programming on the other. On university campuses these two species looked at each other with suspicion, sometimes even with deprecation. If the atmosphere between business and IT is poisoned anyway, which is not a rare constellation, it is embarrassing how such meetings can easily distort into recriminations. The enterprise architect sits on the borderline between these two camps, and the best thing for him to do is to take on the role of moderator. This requires a good dose of political aplomb.

Modeling the architectures (EA-2)

Models and views of various architectures

Making architecture models probably is what most people primarily associate with the profession of an architect. Software developers expect the architect to come along with a blueprint for implementation. Managers expect they have to gaze at annoyingly complex diagrams when an enterprise architect starts explaining why a cable fire affected so many business processes.

Models are abstractions of some part of reality. They suppress irrelevant details but strive for being accurate with respect to the points of interests. Models are always bound to a certain purpose; otherwise there is no way to tell what is relevant and what is not. An enterprise architect, for instance, models the way IT is currently used in the enterprise as well as the roadmap to future use. But she typically does not model the air conditioning in the server rooms or the cabling for employee workplaces. What goes into the model and what is left out depends on the model’s use cases, and there is a wide range of things that can be done with an enterprise architecture model, namely:

• Design and planning. The model is a tool for designing the future evolution of the enterprise’s IT. It is a means to identify the gaps between as is and to be and the corresponding needs for action.

• Analysis and assessment. The model helps analyze the impact of incidents or changes. It allows assessing issues such as strategic fit, compliance with laws and regulations, or risks.

• Implementation and operation. The model is a framework of orientation for detailed design. It is a knowledge base for operating and maintaining information systems.

• Communication and enforcement. The model is a foundation for explaining and motivating changes. It is a means to assure that the intended architecture is actually implemented in the intended way.

There are probably more use cases than the ones we’ve listed, but this selection suffices to characterize the model as an important asset of enterprise architecture management. On the other hand, making and maintaining a model is laborious and expensive. Therefore, one should not ride a hobbyhorse when doing so but instead stick to what the actual use cases require. Striving for completeness, true-to-detail reproduction of reality, compliance to some architecture standard as an end in itself, or gold-plating the model is a waste of effort.

Communication is a use case deserving special attention. The enterprise architect uses the model to answer specific questions of stakeholders. Take, for example, the country head of an enterprise’s Mexican branch. He wants to learn about a new global business process that is planned to replace a local mode of operation. Concerns like this are not directly addressed by the model itself, and the enterprise architect is well advised not to present raw model material such as business process modeling notation (BPMN) diagrams to senior managers. Stakeholders have a specific viewpoint on a subject, and their perspective must be addressed by a corresponding view on the model.

The country head, in our example, wants to know whether the business process replacement changes the roles and responsibilities of his personnel, whether there are any investments needed, and how the IT total cost of ownership is affected. Other aspects such as strategic fit with the global IT strategy are of little interest to him. It is the enterprise architect’s job to draw a tangible view, custom-tailored for this specific stakeholder.

The distinction between model and view is sensible and commonly made.² There actually are technically oriented people who believe that the model is the sheer truth, whereas views are what you “tell the kids.” But the enterprise architect who seriously takes the role of mediator between the various parties who have stakes in IT should abandon this somewhat nerdish attitude.

A holistic view of the enterprise’s IT requires more than one architecture to cover all aspects. On the business side, we have the business architecture that is concerned about the business goals, key performance indicators, organizational units, geographical locations, processes, business capabilities, and even more entities of the business realm. On the technology side there is the infrastructure architecture, consisting of servers, networks, data stores, software products, standards, frameworks, and further miscellaneous hardware and software thingies of which a runtime environment is composed. The TOGAF framework we are going to take a closer look at in Chapter 4, “EA Frameworks,” distinguishes as many as four different architectures that are layered from the business architecture down to the technology components: business architecture, data architecture, application architecture, and technology architecture.

Visualizing cross-relations and transformations

Enterprise architects are in charge of making the entanglement of business and IT comprehensible. The models they create must therefore capture relations between all architecture layers, from business down to technology. Likewise, the views on top of these models should visualize how the entities of the layers, which in a first approach appear rather isolated, are in fact interwoven. Figure 3-4 depicts a highly simplified but typical example from a fictitious logistics company.

Figure 3-4 Process map.

This process map draws a relationship among business processes, the organizational units in charge of them, and the applications supporting these units in their duties. It highlights, for example, that the organizational Unit B uses a rather old 2.3 release of the CRM system, whereas Unit E is already equipped with the more modern release 3.0. As a consequence, Unit B has to work with the legacy applications GDA and DES to manage the whole pickup and delivery processes.

Another kind of view that is widely used to visualize relations is the cluster diagram. Figure 3-5 is, again, a highly simplified example of a more technically oriented cluster diagram that draws a relationship between technology platforms and applications based on those platforms. The applications are sorted into clusters according to the technology they are built on; the reader can learn from it, for example, that release 7.1 of the Settlement application is built on an exceptional technology mix (MS SQL Server and JBoss) that might not accord with an enterprise’s technology standards.

Figure 3-5 Cluster diagram.

We can choose from among a large variety of process maps and cluster diagrams. The process map can, for instance, also be used to visualize relationships between processes, supporting application functions, and business objects involved in these functions. But the two examples shown should suffice to illustrate how they address relationships, dependencies, and cross-concerns. The reader interested in a broader treatment of best-practice EA views may refer, for instance, to Hanschke (2010).

Another peculiarity of enterprise architecture models is that they have a time dimension. The models do not merely present a snapshot of the architecture(s) at a particular point in time; they capture the current state, the future desired state, and possibly a roadmap of transition states along the way. Figure 3-6 is a simplified example of an application roadmap addressing the evolution of the application landscape.

Figure 3-6 Application roadmap.

Another frequently used means of eliciting “Aha!” effects of how things will evolve is a flip-book of consecutive states, like the one in Figure 3-7. The two consecutive states show the simplified application landscape of a logistics company, clustered by functional domains. The arrows mark the data flow with regard to a central business object. The flip-book now clearly demonstrates the effect of an application rationalization on this flow.

Figure 3-7 Flip-book visualization of an application rationalization.

There is an abundance of variants of such landscape maps. You may use them to relate applications with technology stacks, business objects with application functions, or whatever results in a better understanding of how the bits and pieces fit together.

Modeling standards

The notation, terminology, and conceptual meta-model of enterprise architecture models are not standardized in practice. Unlike software design, where most practitioners nowadays agree that the Unified Modeling Language (UML) is the language in which to express software architectures, there is no such convention about enterprise architecture. Some core concepts such as business process can be found in most models; even there the notation and maybe also the definition are not unanimous among enterprises. The modeling language being used in an enterprise is formed by the vocabulary of concepts that has grown over the years, condensing much of the organization’s view of the world as well as the vendor-dependent taxonomy of the modeling tools that are in place.

The nonexistence of a universally understood, reliable language to communicate about enterprise architecture has become an obstacle—even more so in a business context that increasingly counts on collaboration between people and joint ventures of partners. ArchiMate is a modeling standard that is supposed to overcome this obstacle and that up to now remains the only serious attempt to standardize EA notations.

ArchiMate was designed by research institutes and universities in the Netherlands from 2002 to 2004. Since 2008 it has been under the stewardship of and published at The Open Group (2008). As we shall see in the description of the TOGAF framework in Chapter 4, the taxonomy of ArchiMate resembles TOGAF’s own content meta-model. ArchiMate therefore is a perfect fit for modeling the architecture layers along the phases of the TOGAF Architecture Development Method.

Figure 3-8 shows an example of how ArchiMate models a simplified pickup and delivery process that belongs to the core express business of any logistics company: Customers can ring up a call center and request the pickup of a parcel from some place in order to get it transported to a destination address.

Figure 3-8 ArchiMate model example.

The standard distinguishes three modeling layers—namely the business, application, and technology layers; they are depicted by different shadings in Figure 3-8. Let’s briefly traverse these layers from top to bottom to get to know the most important concepts of the ArchiMate taxonomy.

First we learn from the business layer that the pickup and delivery process consists of three subprocesses: pickup, transport, and delivery. Furthermore, the process implements the pickup service, a business service offered to customers as a part of the parcel shipment product governed by an express contract. The service is supported by call center agents and used via the order acceptance business interface by customers that have registered accounts. The process is triggered when a customer calls up the pickup service and thereby issues a pickup order business event. The customer submits information such as the consignee address, which is comprised in a new shipment business object.

The next layer, application, tells us that the pickup subprocess is supported by the order management application. The application offers a process order application function that is used by the call center agents via the order entry API, the user interface of the application. Furthermore, the order management application invokes an API of the dispatching application to assign orders to pickup routes.

The bottom layer eventually shows how infrastructure components such as database systems, servers, and network segments host the order management application.

Though rather simplified, the example conveys an impression of how ArchiMate models entities, in particular of the granularity of detail it addresses. The decomposition of the process, for instance, is much coarser than the detailed flow modeled by a BPMN³ diagram. The modeling of applications does not go deeper than the delineation of applications and their functions and interfaces, which is much less than what is usually captured in a UML model. This granularity is quite suitable for modeling larger parts of an enterprise IT-landscape, and the ArchiMate vocabulary, which is summed up in Table 3-3,⁴ indeed offers the concepts needed to do so. Furthermore, the standard also addresses the requisite cross-relations from business down to technology, which is a major concern of EA modeling.

Table 3-3 The ArchiMate Taxonomy

But ArchiMate also has some shortcomings.⁵ The concepts are ambiguous and not as straightforward to apply as intended. In practical work, you often start wondering whether, for instance, this portal page now offers a business service, a business function, or an application interface.

When it comes to communication, models like Figure 3-7 also tend to be a trifle bulky; such drawings must be interpreted and simplified by views to convey a message to stakeholders. ArchiMate proposes some standard views that leave out model elements or use simplified relationships to come to drawings that are simpler to grasp. (For more details, refer to the chapter “Architecture Viewpoints” in The Open Group [2008].) But in practice the architect needs to expend some creativity to create additional views in PowerPoint so she can get her ideas across.

Although ArchiMate is not that old as a standard, there are already remarkably many EA tool vendors claiming support of the standard—for example, Rational System Architect by IBM, BizzdesignArchitect by Bizzdesign, or Abacus by Avolution. There is also an Eclipse-based open source tool for drawing ArchiMate models, called Archi⁶; maintained by the University of Bolton (UK), it accurately implements the standard and works well in practical use.

But managing the enterprise architecture with Archi, Microsoft Visio, or any other plain drawing tool is an impossible undertaking. The costs of keeping the data up to date are prohibitive, and the rift between model and reality will soon be insurmountable. Such drawing tools fall short of the major requirements an EA toolset should fulfill beyond capturing plain models, namely:

1. The tool has a timeline for planning and simulating future states of the architectures.

2. It supports quantitative assessments and optimizations of the IT landscape; in other words, it supports application rationalization.

3. It has rich facilities to visualize models and craft views addressing specific stakeholder viewpoints as well as publishing functions for sharing knowledge.

4. It is integrated with other tools, as depicted in Figure 3-9.

Figure 3-9 An EA dream: The integrated EA tool.

5. It facilitates communication by feedback, collaborative authoring, and other means of participation.

Dedicated EA tools such as Rational System Architect or Abacus more or less fulfill requirements 1 through 3. But there are no tools on the market yet for making the enterprise architect’s dream of integration with all related sources of information come true. Such an unobstructed synchronization of data would be a powerful weapon in defeating the drifting apart of EA models and reality, a safeguard “that which must not, cannot be.”⁷

Wide-ranging IT-management tools such as alfabet’s planningIT offer EA and some of the neighboring functionality in one product offering, but they come with a price tag that is hard to sell to the chief information officer (CIO) “just for architecture.” In addition, this approach does not help if there already are other CASE⁸, CMDB⁹, or what-have-you tools installed. But even if the CIO is in a spending mood, the price tag restricts such tools to a small circle of authors since they mostly are desktop applications licensed per user.

Some creativity is required to balance the need for up-to-date EA models with the integration costs of the vision expressed in Figure 3-9. Since there are no standard integration interfaces, the realization of any synchronization arrow of the diagram in most cases means investing in custom implementation. The maxim here is to make the best of an existing blend of tools for EA purposes.

On the other hand, a manual refresh of the models is strenuous and has a slight ex post skew: just documenting what has been implemented. Manual refresh usually is a dead end because it only allows for modeling an isolated core of high-level entities. The result therefore misses an important requirement of architecture models: They should be continuous and ideally should support a seamless drill-in from high-level application landscapes to fine-grained class diagrams, project schedules, configuration parameters, operational incidents, and so on.

Finally, stale and unfertile architecture models can only be avoided by inviting a wider audience to take part in architecture concerns. This demand is expressed by requirement 5, and we’ll embark on it in Chapter 8, “Inviting to Participation.” It again stresses the importance of collaboration—this time not with adjacent information systems, as in Figure 3-9, but with the people involved in IT. Today most EA tools are pretty weak with respect to participation. They mostly support a one-directional publication by architects to the world but don’t implement feedback channels. Chapter 8 will give us an idea of how to overcome this obstacle.

The short list of requirements we’ve set out can be taken as a starting point for educated selection of an EA tool. More guidance and a checklist for tool assessment are available in, for instance, Schekkermann (2011).

Evolving the IT landscape (EA-3)

Application rationalization

When you can measure what you are speaking about and express it in numbers, you know something about it.

—Lord Kelvin (1824–1907)

In Chapter 1, we learned that Dave Callaghan, the CIO of our fictitious Bank4Us, mandated 20% savings over the next planning period in a strategic statement and explained further that:

The savings will be attributed to legacy reduction/downsizing, reduction in number of system interactions, and reduction in IT operation/support cost.

Now, Bank4Us is running more than 3,000 applications in its data centers. Such a number of applications of different generations tends to proliferate to an entanglement that resembles a rampant jungle. Ian Miller and his group of enterprise architects take the CIO’s statement as an imperative to boldly thin out this jungle. But how can they accomplish this kind of cultivation?

Identifying applications and key performance indicators

The first major step in such an initiative of application rationalization is, evidently, to get an overview of the current set of applications. As a prerequisite, there must be some guidelines that nail down what counts as an application.

Applications

What Is an Application?

Though the term application is a central notion of IT, there is no commonly accepted or precise definition of this term. The Open Group (2011) defines the term in its TOGAF standard as:

A deployed and operational IT system that supports business functions and services; for example, a payroll. Applications use data and are supported by multiple technology components but are distinct from the technology components that support the application.

This explanation leaves room for interpretation and certainly is not a sufficiently sharp delineation to come to a catalogue of enterprise applications in a straightforward manner. Further discussions are to be expected. Keller (2007) even claims that the struggle for an explicit definition of application is somewhat pointless because the domain experts working in a business unit already know their usual suspects. There’s some truth in this view, since the term application will always remain fuzzy to a degree. The identification of applications therefore needs to be backed up by the intuitions of domain experts. Nevertheless, there must be in place some guidelines that are sufficiently sharp to ensure that one doesn’t end up comparing apples with oranges across the business units. If one business unit counts single Java EARs¹⁰ as applications, a moderately complex three-tier IT system with database, business logic, and presentation tier can easily consist of 100 applications. If another unit counts such a system as a single application, the enterprise-wide comparison is out of balance.

The guidelines for identifying applications probably differ from enterprise to enterprise and certainly depend on the granularity of the enterprise’s architecture management. But as a starting point we suggest the following common traits of applications:

• They provide end-user functionality (as opposed to mere system software).

• They provide cohesive functionality having a common purpose.

• They are somewhat self-contained deployment units.

• They are logical entities in the sense that they are to some extent independent from the implementation technology.

• They have an owner who is responsible for development and maintenance.

The enterprise architects at Bank4Us are well prepared with a sufficiently up-to-date catalogue of applications at hand. In companies without an enterprise architecture practice, the composition of such a catalogue can be the first painful, laborious obstacle.

Given such a catalogue, the next step is to quantify what should be improved. This implies the agreement on some key performance indicators¹¹ (KPIs) that one wants to optimize—numeric values that should be increased or decreased. Ian Miller and his team decide that the CIO’s directive is best measured by the following KPIs:

• Total cost of ownership (TCO) of an application. This entails all costs related to the application: Development of new features, maintenance, trouble-ticket resolution, server costs, license fees, and whatever else is on the bill for changing or running the application.

• Strategic fit (SF) of an application. This KPI tells to what extent an application is considered “legacy” on a scale from 1 to 10. It captures both technology and business aspects. An application scores high if it fits well with the envisioned business architecture, is built on standards and products that are considered future proof, and is in its prime with regard to the software life cycle.

• Value contribution (VC) of an application. This measure reflects the business value generated by the application. There are only few cases where a definite amount of money can directly be associated with an application; in most cases, the VC will be a unitless value, like strategic fit. VC summarizes the importance of the application for the business processes it supports, how well it supports them, and what revenue streams are involved in these processes. This KPI reflects the business criticality of the application as well as the impact of replacing or retiring it on the organization.

• Fan-in and fan-out of an application. The fan-in of an application A counts the different data flows entering A in the course of processes directly or indirectly supported by A. These data flows can be interface invocations by other applications, messages consumed by A, or global data structures—for instance, database tables read by A. The fan-out, on the other hand, counts how many data flows leave A. These can be interface invocations by A on other applications, messages sent out by A, or global data structures modified by A. Henry and Kafura (1981) have proposed these KPIs as measures of procedural complexity.

Ian and his team conclude that these four KPIs should suffice. Further measures just make the comparison of applications less comprehensive. They also agree on the weight each KPI should get in a comparison, and they play for a while with the idea of an all-comprising KPI-formula, such as:

But then they drop this “world formula” idea because it gives the simplistic impression that decisions could be based solely on a quantitative assessment of this variable.

The slightly complicated fan-in and fan-out KPIs are there to capture the CIO’s statement that the number of system interactions should be reduced. They raise some discussions about why the CIO included this reduction in a strategic initiative that primarily is about cost savings. Ian explains that this is because the total costs of an application landscape are a mix of application costs and interface costs, as schematically shown in Figure 3-10.¹²

Figure 3-10 Application and interface costs.

The distribution of functionality to many applications results in a highly modular landscape with increased interface costs. Take, for instance, the costs to keep several versions of an application interface concurrently alive in order to serve both new and old clients—these costs do not occur, if the same functionality is integrated into a single application. But integrating widely unrelated functionality into a single application, on the other hand, also generates surplus application costs. The hardware costs, for example, are higher with each installation, and the synchronization overhead of development projects also adds to the bill. To find the proper cohesion and compromise between modularity and integration is a U-curve optimization, and the Fan-In/Fan-Out KPI’s can help quantifying it. As a general rule, only a medium Fan-In/Fan-Out value allows for a minimal Total Cost of Ownership (TCO)—both minimizing and maximizing the Fan-In/Fan-Out will at some point increase the TCO.

This exemplifies an important point about application rationalization: The KPIs to be optimized seldom are independent variables. The expectation to freely lift them all to an optimum is misleading. As Garajedaghi (2011) puts it, there is a certain slack between the variables: One variable can be modified as if it were independent in some range of tolerance, but there is an excision where it starts affecting the others.

The best thing to hope for is, therefore, some equilibrium representing a local optimum. A more practical consequence for now is that it is crucial to agree on the weight of each KPI and consider the effect of changes on the whole tuple of KPI values.

Assessing applications

The agreement on the KPIs prepares the groundwork for assessing the applications in the application catalogue. The goal is to come up with a table like the one shown in Table 3-4.

Table 3-4 Excerpt from an Application Assessment

TCO Total cost of ownership (K $/year)

SF Strategic fit (rating 1–10)

VC Value contribution (rating 1–10)

Ian picks a common scheme invented by Ward and Peppard (2003) to visualize the score of applications in four different quadrants, as shown in Figure 3-11. This scheme classifies applications into four main categories:

• The Stars ensure the current and future business of the enterprise. They are already used in important business processes and primarily support innovative products or services the company backs on as key differentiators in comparison to their competitors. Their importance for the future business is expected to grow. Furthermore, they fit well into the technology roadmap.

• The Wild Cats, sometimes also called Question Marks, have a certain potential for future business but do not contribute much to the current business operations. In a sense, these are prototypes that still have to prove their usefulness. They typically explore how new technologies can help seize new business opportunities.

• The Cash Cows form the operational backbone of the current business. They ensure today’s core operations and generate the largest share of business from IT. Any outage of such a system is a pain and is likely to end up on the CIO’s desk. But a cash cow does not fit nicely into the envisioned future operations and is technology-wise considered “legacy.”

• The Poor Dogs are not important, neither today nor in the future. In some cases they are just residues, the quick wins for an application rationalization initiative. In other cases they are support systems that are somehow needed but do not make a crucial difference to the enterprise. A typical example is an application for tracking working hours.

Figure 3-11 Ward-Peppard classification of applications.

These four categories have different key quality requirements and therefore must be treated in different ways, as Figure 3-12¹³ indicates.

Figure 3-12 Strategies for treating various applications

It is worth highlighting that EA must show different attitudes to the four quadrants as well: Enterprise architects should not impede the capturing of crucial new ground for Stars and Wild Cats by restrictive quality gates or standardization and integration requirements. Viable applications typically run through a transition from Wild Cats over Stars to Cash Cows, and EA should foster their maturing with smoothly increasing quality constraints.

Another aspect worth noting is that the different categories of applications might claim for different approaches in software development, too. Wild Cats and Stars benefit most from agile software development because of its focus on bringing new features to life.

Cash Cows, on the other hand, are merely maintained and therefore offer no compelling reasons to switch to agile (assuming that this is not the approach the company is most acquainted and proficient with). Furthermore, the upgrade of a central Cash Cow needs extensive nonfunctional tests, requires that users and administrators are trained beforehand, and usually implies the physical rearranging of some core business processes. All this needs planning in advance, which does not fit easily into agile software development, with its functionality scoping on a three-week basis.

Stipulating how the four categories of information systems are to be treated is typically also something achieved in EA-1, “Defining the IT Strategy.” Figure 3-12 is just one typical example of such a stipulation.

Assessing alternatives

Let’s turn back to Ian’s application rationalization journey at Bank4Us. The KPI assessment of the application catalogue gave him hindsight into the applications with a high potential for optimization. The application TR2 in Figure 3-11, for example (a trading application developed in the 1990s, as far as Ian knows), is close to a Poor Dog but causes tremendous costs. Nevertheless, simply ramping it down will be an intricate matter since it shows a lot of interactions with other applications, and presumably it is deeply interwoven into the data- and workflows of the enterprise. But maybe there are other options?

Consequentially Ian’s next step is to deep dive into the refactoring options of each optimization candidate. Can a candidate be ramped down by rearranging some business processes or shifting functionality to some other applications? Can the application be refactored so that it is less interwoven with other systems? Can at least a couple of business functions be taken over by some star applications? Ian and his team discover that a small extension of the Wild Cat trading application TAR (see Figure 3-11) would make a larger part of the TR2 functionality superfluous, with only minor changes to the business processes and one additional system interaction (fan-in) added to TAR.

This appears to Ian and his team as the healthiest thing to do in comparison to other options. Hence, they redraw the architecture models, accommodate this change into the target architecture, and reassess the modified overall landscape once again, as shown in Figure 3-13.

Figure 3-13 Reassessment of a transformation.

Application rationalization is an optimization with constraints, as you can see from Ian’s reasoning. One essential constraint is that the rationalization measures must neither disrupt daily operations nor cause critical changes to the business processes or organization. Therefore, the impact of these measures must be assessed, and this will be the easier the better you have accomplished activity EA-2, Modeling the Architectures. An up-to-date EA model highlighting the relations between business processes, organizational units, services, applications, and so forth makes such an assessment a piece of cake. (Well, this statement needs to be taken with a grain of salt; it still remains a challenge, of course.)

But many enterprises are far from having such a model in place, so the assessment can really become a desperate endeavor. According to our experience, a high percentage of application rationalization initiatives fail, and they fail because of the inability to assess the impact of even humble changes. When you are consulting a company in an application rationalization and you touch the ground for the first time, you’re likely to meet ironic people telling you things like: “We have tried to ramp down application SIS in 2005 and 2007 already, and now you with your supernatural powers come to the rescue?”

The dose of sarcasm depends on the personality, but the reason for the failure of earlier attempts usually is that they unraveled so many unknown ramifications and configurations that people eventually decided they’d better not touch anything. Chapter 1 already reported on highly respected enterprises that lost track of their IT to such an extent that the lunatic “hotline approach” becomes an acceptable reengineering method: Install an emergency phone right beneath the application server, shut the server down, and wait to see who calls.

The Bank4Us example also illustrates that application rationalization is a recursive process. Options that seem promising and feasible are applied to the architecture model, and the resulting target landscape is reassessed using the same KPIs as in the first round. Since the target landscape is just a vision and not operational, one is relying on guesswork here more than usual. But the effect of an improvement must be quantified somehow.

The guesswork character of this projection into the future brings us to an important question: How are the KPI values actually calculated? How did Ian and his team come to the conclusion that the return on equity (ROE) application has a TCO of $390,000 per year but a poor strategic fit of three?

The answer in brief is: Facts and opinions. A concrete indicator such as TCO can mostly be calculated on the basis of facts—by gathering the bills and contracts pertinent to the application under inspection or by collecting maintenance efforts from incident management systems and similar sources. But the evaluation of an imaginary measure such as strategic fit (SF) mostly relies on opinions. To gather them, Ian and his team have conducted a series of interviews with subject matter experts with different responsibilities: business and IT strategists, application owners, software developers, and operating personnel.

But the question “How well do you think the application fits to the strategy?” is too abstract for a non-erratic answer. Most people will shrug their shoulders. Ian therefore decomposes the SF-KPI into about two dozen base indicators and places them on a scorecard, as shown in Table 3-5.

Table 3-5 Excerpt of a Scorecard to Estimate the KPI Strategic Fit

ID	Base Indicator	Score (1–10)
BI1	The application fits into the technology road map	5
BI2	The application supports the strategic goal of customer empowerment	3
BI3	The application supports multichanneling and mobile devices	3
BI4	The application resolves an existing business impediment	7

The scores of the individual base indicators are then aggregated according to some weighted formula to the KPI value of SF.

In collecting opinions, it is crucial whom you decide to ask. The prevalent approach is to nominate subject matter experts and conduct interviews with them. This narrows the circle to a small, illustrious group of adepts whose judgments are hopefully full to the brim with insight. But if the majority of users say that a certain application is cumbersome, the experts’ praise of it is to be taken with care. Chapter 8, “Inviting to Participate,” therefore suggests complementary means of Enterprise 2.0 to come to a broader, balanced assessment.

Summary

Application rationalization is one special but prevalent example of EA-3, Evolving the IT Landscape. It also is an example of a transformation that is not driven by tangible functional requirements but by nonfunctional strategic concerns such as reducing costs or complexity. We have seen how KPIs are the pivotal tool to drive such transformations, right in the spirit of the often-cited tenet by Peter F. Drucker¹⁴ that “If you can’t measure it, you can’t manage it.” They are the key to a precise understanding of the goals, crucial for identifying areas of improvement, and simulating the effect of changes. We also saw how deep dives into areas of improvement depend on how well an enterprise maintains its knowledge about its IT. Only if a sufficiently accurate and up-to-date model of the enterprise architecture is available, one can assess the impact of changes and simulate their costs and benefits.

General IT transformations

The evolution of the IT landscape is not only driven by strategic initiatives—that’s a pivotal thing to note when we’re looking at IT transformations in general. What we mean by strategic initiative is something like Ian’s rationalization project at Bank4Us: The CIO issues a strategic goal, the enterprise architects work out a target architecture matching this goal, identify what has to be done, and mandate the vassals in the development and operational departments to put things into practice.

In most enterprises we have seen so far, these strategic initiatives are not even the main force having an effect on the IT landscape. The decision of an automotive company to intensify marketing by adopting mobile devices or the plan of an ocean carrier to open a wide range of B2B services to logistics partners do not typically stem from the strategic board. In companies with good strategic governance, such initiatives are in line with the strategic direction, but they are nevertheless brought to the table and owned by business units. They also can bypass the desk of enterprise architects: The initiatives are run as business projects, and the target architecture consequentially is in the hands of project architects, who by majority do not belong to the EA group.

The IT metamorphoses that enterprise architects encounter in practice are therefore a mix: In a few initiatives they are the masterminds; in a lot of others, planning and design is out of their hands. In those cases not owned by EA, the role of enterprise architects is limited to taking care that the evolution stays within strategic boundaries (see EA-5, Developing and Enforcing Standards and Guidelines) and to “backfilling” the architecture by integrating the solutions designed by others into the overall picture (see EA-6, Monitoring the Project Portfolio). The development of an IT landscape resembles more of a true evolution, where different actors and purposes try to push their business through, rather than a transformation planned by some mastermind.

Another peculiarity of Ian’s rationalization project is that it takes applications as a focal point. Applications traditionally are the units of ownership, deployment, and maintenance; they also are things that are internally well known and distinguishable as icons on the company desktops. But they are not the only possible focal point, maybe not even the best one in a modern architecture.

Dave Callaghan, the CIO of Bank4Us, also mandated customer empowerment as a strategic goal. But the customer view comprises products, contracts, services, business user interfaces, or customer processes. The enterprise’s applications are aliens from this viewpoint.

Wouldn’t it therefore be more natural to take the business architecture as a point of departure, instead of immediately gazing at applications? Then, the paramount step toward customer empowerment would be to draw a picture of the as-is landscape of services, business interfaces, and products and to design an improved to-be landscape offering more functions, processes, and a lighter access. Only the second step would then jump to applications and explore the options to support the envisioned business architecture by application functions and collaborations.

This is roughly the order prescribed by the TOGAF Architecture Development Method (ADM), which we take a closer look at in Chapter 4, “Architecture Frameworks.” The last step in ADM, leading to a full blueprint of the CIO’s customer empowerment mission, is mapping the application architecture to technologies—the software components, third-party products, standards, servers, routers, and what else there is when getting down to the nitty-gritty. This priority order—from business architecture over applications to technology—shifts the focus from a technology-centric to a business-centric design. It better fits initiatives that have a business momentum instead of an IT momentum, such as bringing down application costs.

The strong use of KPIs is the last peculiarity of application rationalization that needs to be differentiated when we’re looking at IT transformations in general. Many strategic goals are qualitative by nature, as we can see from the Bank4Us goal of customer empowerment, and their translation into quantitative values seems rather artificial.

Often the assessment of target landscapes simply compares the different alternatives against a checklist of requirements. Compliance is noted by a checkmark, and the pros and cons of exceptions are discussed with regard to contents but without referring to numeric values. Nevertheless, it is worth striving for a KPI representation of qualitative goals, even if they are just unitless score values, as shown in Table 3-7. Three primary reasons count in favor of quantification:

• The compliance with a generic goal, such as customer empowerment, usually is not a matter of “either/or” but of “more or less.” There are many shades of gray between “black” solutions that do not empower customers at all and “white” ones that make customers crowned regents. These shadings can only be captured by numbers.

• The assessment of alternative target architectures in EA covers a large area of the IT landscape. The cases in which one alternative outplays the others in all dimensions are rare and do not cause much headache. It becomes interesting if an alternative offers more customer empowerment in some applications but scores lower in others. In such a case, some aggregation algorithm is needed to come to a holistic comparison.

• The formulation of KPIs sharpens the understanding of a goal. This is in line with Lord Kelvin’s tenet that the ability to express something in numbers signals a deeper understanding of the subject. Qualitative is sometimes just a euphemism for fuzzy.

SOA transformations

Transformations toward a service-oriented architecture (SOA) belong to the more technically driven changeovers of the IT landscape one frequently encounters today. Some time ago there was a debate about the slogan “SOA is dead,” put into the world by the Burton Group (Manes, 2009). Still, the larger firms we’ve seen over the past few years have kept SOA on their strategic agendas.

For good reason, SOA is a very suitable architecture paradigm for designing large software systems. The proposed next-generation replacements, such as Sam Ruby’s Resource Oriented Architecture (ROA) (Richardson and Ruby, 2007), did not make it to the enterprise IT agenda. Maybe this is because they are not true replacements of SOA but instead are necessary extensions of a too narrow understanding of “services.” The term service had found a rather one-sided interpretation by the WS-*¹⁵ Web services and the extension to REST¹⁶ and other implementation styles of “service,” which is the core of ROA, WOA, MOA¹⁷ (and so on) just correct this narrow-mindedness.

But a truth behind the provocative “SOA is dead” is that SOA certainly is past its peak of inflated expectations. Today it will be difficult to find sponsors and followers for an initiative that turns the whole enterprise IT upside down just for the sake of SOA. If SOA is still on the agenda, it is an architecture standard for changes that are needed for other reasons, but not an end in its own right. For example, the ocean carrier striving for a B2B integration with its logistics partners will probably build a solution in the SOA way. As a side effect, the IT landscape moves closer to SOA in that case.

Nevertheless, there are considerable advantages of SOA, regardless of any hype cycles:

• Business-centric design. A good SOA design sets the priority on business capabilities and processes.

• Reuse of functionality. SOA services expose functionality with a potential for wider cross-organizational use. The SOA paradigms of encapsulation, statelessness, and service-level agreements help in utilizing existing assets in many contexts. Furthermore, SOA services have a coarse granularity and thereby avoid the felt-like weave of distributed interactions that made earlier attempts with distributed objects (e.g., CORBA¹⁸) fail.

• Flexibility. SOA clearly separates control logic from business logic and data: The control logic is incorporated in processes, whereas business logic and data are made available by services. This allows for a flexible mapping between the two parts of the game; ideally, processes can be rearranged without much impact on the services, and vice versa.

• Multichanneling. SOA also separates the presentation logic from control logic, business logic, and data. This implies that the business processes, functionality, and data are no longer bound to a particular end-user application. You can start a process from your desktop, take the next step with your smartphone, and receive progress reports via Short Message Service (SMS).

• Decoupling of functionality and technology. Business architecture and technologies have different life cycles. The technology-agnostic concepts of SOA introduce a level of abstraction that protects the business functionality from heterogeneity and change in the underlying technical infrastructure.

• Stability. The SOA concept of loose coupling and the corresponding techniques stabilize the IT landscape. Outages and performance fall-offs become locally isolated and no longer drag along contiguous applications.

The business-centric design aligning business processes and services with underlying application functionality makes SOA an ideal ally for EA. Both have business-IT alignment on their primary agenda. “SOA provides a unique chance for the first time in IT history to create artifacts that have enduring value for both, the business as well as the technology side,” write Krafzig, Banke, and Slama (2006). They see SOA as an approach for renovating the IT landscape and SOA governance as a means of enterprise architecture management. But given that the IT landscape consists of vast areas with good old mainframes and other assets far off from service orientation, it should be clear that EA must have a much wider scope.

Assessing and building capabilities (EA-4)

Draupadi,¹⁹ the heroine of the Indian epic Mahabharat, emerged as a full-grown woman from the sacrificial fire (Yagnya), and proclaimed to the whole world that she was immaculate. Unfortunately, we do not have any such mechanism to produce fully equipped enterprise architects “just like that.” The scarcity of enterprise architects (or the right IT resources in the right positions, in general) is quite evident in the IT industry. Despite attractive offers, many IT positions remain open, waiting long for “true love’s kiss.” In some cases, they are inappropriately filled, and in some others their tasks are silently stapled to the job descriptions of the enterprise architects.

The face of IT is changing continuously and rapidly. On the one hand, it is becoming more commoditized, centralized, and outsourced. On the other hand, IT is venturing into providing value-added services to the business, like business process design, product design, business transformation and innovation. As a consequence, the portfolio of IT service offerings is expanding, and IT leadership is becoming more and more crucial. Ross (2011) states:

If, despite the emergence of a digital or information economy, the business leaders are not positioned to lead IT-enabled business transformations (…), the need for IT to do so becomes acute (…). Ensuring the right talent to realize the IT organization’s ambitions is a critical challenge, many CIOs told us.

The question on the CIO’s table is: Is the current workforce equipped to adjust quickly and effectively to the challenges ahead? The activities in the IT unit are gearing toward business process engineering, architecture realization, and program management. This goes far beyond mere application development, system implementation, and project management, which were sufficient only a few years ago.

As a consequence, enterprises are realizing the importance of strategic competency management—an antithesis to the reactive demand fulfillment of the past. In the ideal case, they actively look at the future possibilities, demands, and constraints in the organization. This means developing long-term workforce plans, defining multiple career paths, investing heavily in their people, facilitating internal and external training programs, and offering rotations between business and IT roles.

Competence development for enterprise architects

In the first century BC, Marcus Vitruvius Pollio²⁰ described an ideal architect as follows:

A man of letters, a skilled draftsman, a mathematician, familiar with historical studies, a diligent of philosophy, acquainted with music, not ignorant of medicine, earned in the responses of juris consultis, familiar with astronomy and astronomical calculations.

Today the image of an enterprise architect in IT continues to be loyal to this 2,000-year-old definition—in the sense that an enterprise architect in today’s information age is perceived as a multidimensional personality. She knows a lot of things and can do many things. The role of enterprise architect entails:

• Making important and (quite often) difficult decisions single-mindedly, to ensure the conceptual integrity of the enterprise’s business and IT; moreover, she needs to take those decisions early enough so that a plan is in place for everyone else to follow (see Activities EA-1, EA-2, and EA-3).

• Being cognizant to what is going on in the projects, watching out for important issues, and addressing them before they get out of control; at the same time, she has to work in intense collaboration across the projects (see Activities EA-5, EA-6, EA-7, and EA-8).

• Communicating at technical and nontechnical levels with conviction and restraint; quite often this requires us to stand up in a meeting and convey bad news to the sponsors or stakeholders in the most sensible manner (relates to all Activities EA-1 through EA-8).

• Keeping the organization on-ramp and on par with technology advancement in the industry (see Activities EA-1, EA-3, EA-5, and EA-6).

In a nutshell, the role of enterprise architect demands a plethora of multidisciplinary skills. This includes hard skills such as business acumen, technology expertise, and project management. Even more important are soft skills such as executive communication, collaborative influence, and organizational leadership.

Competency tree for an enterprise architect

The first step in profiling an enterprise architect is to build a competency tree. This means identifying the competency areas relevant to the enterprise architecture, organizing them in a structure, and defining associated proficiency levels.

A competency area entails the body of knowledge pertaining to a subject or a field of study. These can be areas as different as customer relationship management, enterprise data management, integration patterns, Web 2.0, agile methodology, or project management. The proficiency levels help measure an individual’s depth of knowledge and level of experience in a given competency area. The competency areas for an architect can typically be grouped under four main capability streams:

• Business acumen. This pertains to an individual’s knowledge, skills, and experience in the specific business domain under consideration. For instance, the IT organization in Bank4Us needs broad and deep insight into the banking domain, ranging from the basic account-opening process in retail banking up to risk analysis and hedging of exotic derivative products in investment banking.

• Technical expertise. This of course is the core competence required for any IT organization. It depends on the technology environment of the enterprise as to what expertise is required there. In Bank4Us, deep know-how in mainframe, Java/JEE, packaged CRM, Unix/C, and relational database management systems (RDBMS) such as Oracle, DB2, and MS SQL Server are valued.

• Process excellence. This deals with the knowledge about main IT processes, comprising software engineering (for example, agile and waterfall), quality management, operational management (e.g., ITIL), program management, investment and risk management, procurement, and vendor relationship management.

• Organizational leadership. This area primarily comprises people and behavioral skills pertaining to team leadership, intense collaboration, communication, and negotiation.

A balanced competence framework should list about 10 relevant competency areas for each of the preceding capabilities. If needed, this structure can be further enhanced—for instance, by decomposing a competency area into a three-level tree showing a subject area (root), topics (branches), and learning modules (leaves). Such a tree is specific to the skills and experience requirements in a given enterprise and needs to be set up with hindsight into the context of market opportunities, organizational needs, and environmental constraints of that enterprise.

Having defined the competency tree, the proficiency of an individual in a given competency area can be ranked using a set of evaluation criteria. Here is a suitable scale of five levels:

• Level 1. Limited knowledge, basic awareness.

• Level 2. Trained, conceptual knowledge, some educational background.

• Level 3. Applied knowledge; is able to design and optimize a solution approach under supervision.

• Level 4. In-depth knowledge; masters the current state of art and is able to design and optimize a solution approach independently; can guide project teams; acts as an advisor to others.

• Level 5. Expert; advances the state of the art; industry recognition; international publications; speaker at conferences (maybe even delivering keynotes); panel member in standards bodies.

Table 3-6 shows an illustrative enterprise architect skill profile for Ian Miller, enterprise architect at Bank4Us.

Table 3-6 Ian Miller’s Bank4Us Enterprise Architect Skill Profile (As an Illustration of the Concept)

One practical question remains: How should one measure and assess an individual’s proficiencies in each of the stated skill areas? A proprietary profile definition, as shown in Table 3-6, can be replaced or extended by adopting the Open Certified Architect (Open CA) program as a standard mechanism to benchmark an individual for her architectural competencies. Open CA is an architect certification offered by The Open Group. It qualifies an individual to be a practitioner architect based on a stringent evaluation of that person’s skills and experience in the role of an architect. The certification is offered at three role levels or positions:

• Level 1. Technical architect, typically architects working at project level.

• Level 2. Master architect, for architects normally working at program level.

• Level 3. Distinguished architect, usually architects focusing at enterprise level.

In essence, the Open CA certification program offers a yardstick to qualify an architect using fairly precise and measurable criteria. It is certainly not 100% foolproof, yet it is worth a serious attempt.

Building the competence

When organizations take a strategic view on the career progression of their IT staff, they tend to spend more money training them. The training may be facilitated through external training institutes or channelized through online media. However, beyond a certain point, only experience (and not knowledge) counts. You can acquire the tacit knowledge needed for higher proficiency levels only through your own experience and, to some extent, by learning from the lessons of experienced people in the field. Job rotation is a good tool to get adequate exposure and experience in the field of aspiration. In addition, the enterprise architect should join a community of practice in her interest area.

A rather easy way of job rotation is for architects to spot business analysts and technical developers who would make good architects. These professionals’ intrinsic talent can be sensed by looking at the kind of questions they ask about their projects. For instance, are they curious to know how their solution is going to be used by the business? What benefit it is going to deliver? How is their project linked to other projects? This constant analysis helps elevate or change their roles to make the best use of available (and rather scarce) talent as well as to offer them better exposure to be a good architect.

Another way of job rotation, especially for practicing architects, is to switch position between strategic activities to operational activities at regular intervals (maybe quarterly or semiannually). The balance of strategic and operational experience must be a prerequisite for promotion to the next level.

It is also a best practice, if it is possible, to recruit or depute people from the business side to the IT side, and vice versa. This applies especially to businesspeople with project or program management backgrounds. They can be more easily groomed to acquire technology management expertise. In addition, they bring their business acumen and experience to the IT crowd.

In a similar manner, IT personnel with reasonable business understanding can be deputed into business—as apprentices and ambassadors, especially engaging them in the activities related to process modeling, process analysis, data analysis, business executive training, and so forth. Enterprise architects need to have complete and rounded personalities to be successful. This can only happen if their career progression spans strategy and operation and across business and IT.

Although learning by experience is the best way, it is a rather long process. Learning from others is a reasonable approach, too. There are many ways to facilitate this type of learning. A community of practice consists of a group of people bound together by shared expertise and a passion for a joint mission, working together to foster and develop knowledge. It provides a sense of belonging to the individuals working on different projects and a platform for sharing and developing common competencies.

Evidently, a community of practice requires an economy of scale in terms of opportunities and demands for it in order to become a viable, sustainable, and successful venture. In essence, it is meant to fulfill needs in a specific competency area by proactive provisioning of:

• A skilled and trained workforce

• Strong partner relations

• Tested and proven technical solutions and development methodologies

We will look into new avenues of fostering a community culture in the organization in Chapter 8, “Inviting to Participation.”

Formalizing enterprise architecture

One of the top concerns while setting up a new enterprise architecture practice is to figure out who in the organization should do what. There are many questions to answer:

• How should the enterprise architecture team be organized?

• What skills does it have to possess?

• Where does it report to?

• How does it engage with other stakeholder groups?

• How is funding organized?

• What decision authority does it have?

The list is certainly not exhaustive. There are many options to consider, and there is no one right way to implement and operate an enterprise architecture practice. It depends on many organizational factors such as business imperatives, operational model, and governance structure of the enterprise.

TOGAF, the Open Group EA framework that we will cover in detail in Chapter 4, does provide a few hints in this direction. The preliminary phase of the TOGAF Architecture Development Method (ADM) describes a typical approach for initiating EA for an organization. In addition, consulting firms like Gartner also help the organizations set up an enterprise architecture practice.

Team organization

Normally, the scope of EA is larger than what enterprise architects can handle. It is too much work for one person to manage and too much work for one centralized group of people to deal with. On one hand, it requires a lot of breadth and depth of knowledge and experience. On the other hand, it needs quite some coordination and collaboration. Moreover, the enterprise will not stand still until the EA team has plotted its course of action; it will continue to operate in its “business as usual” way while the enterprise architects are preparing the course of corrective actions.

In view of such organizational constraints, the best positioning of EA is probably as a community of practice that operates at three levels:

• Core team. Owns and operates enterprise architecture; small in size.

• Extended team. Subject matter experts, key contributors, working committees, governing bodies.

• Community. Interested parties, project team participants and contributors, users.

The core team comprises full-time resources dedicated to the EA practice. Profiles of core team members should reflect a broad coverage of skills and a diversity of experience and soft skills rather than a deep specialization in specific technologies. Generalists are typically preferred over specialists. A deep familiarity with the business domain and processes is of equal or even higher importance than IT technology mastership. Typically, members of the EA core team should originate, in roughly equal parts, from business and IT departments.

The extended team consists of well-respected experts in their respective field of expertise—business or IT. They are typically specialists who are invited into the EA fold by solicitation. The extended team comes into action on an as-needed basis. The members normally engage as part of working committees or governing bodies that are geared toward a specific focus area currently under incubation or investigation by the EA team. This can be, for instance, a working group for digital marketing strategy, customer analytics, information security, anti-money-laundering vigilance, or cloud sourcing, to name just a few examples.

In addition, the CIO (or chief architect) may also appoint an architecture review board (ARB) to manage the review of projects and assess project alignment with the enterprise architecture. In a way, the ARB is an extended team that assesses each proposed project or investment for compliance with EA.

The community members are the users and stakeholders of enterprise architecture. The community includes corporate leadership, business leaders, business relationship managers, senior IT executives, and, more important, project teams and business users.

With respect to the structure described here, an enterprise architecture practice can be viewed as a core team plus a dynamic virtual team, functioning simultaneously at any given point in time.

Team composition

To begin with, the core team must have at least one full-time person who is fully responsible for the enterprise architecture. This is ideally the chief architect, appointed by the CIO. The chief architect is an executive position that serves a dual role:

• Architect in charge for the enterprise’s IT landscape

• Chief program manager for enterprise architecture initiatives

The chief architect is supported by the core team of architects, as described. The core team is typically a pool of enterprise architects that in turn is supported by an extended team of business, application, data, and infrastructure architects. Table 3-7 provides a typical listing of functional roles and associated responsibilities assigned to the core team members. Often some of these roles and responsibilities are shared, paired up, or contracted out.

Table 3-7 Enterprise Architecture Core Team: Functional Roles and Responsibilities

Role	Responsibilities
Chief architect	Heads the enterprise architecture practice; organizes and manages the core team; directs development of the baseline and target architecture.
Enterprise architect	Provides architecture strategy and planning consultation for the enterprise, business units, and project teams.
Business architect	Models and describes business processes, scenarios, and information flows.
Information architect	Analyzes and documents business information needs, logical and physical data models, and associated relationships.
Application architect	Specifies application interfaces, control logic, and data flows.
Infrastructure architect	Analyzes and describes system environments, including hardware, operating systems, application software configuration, network and communication infrastructure.
Security architect	Focuses on IT security aspects in the enterprise architecture, including design, operations, encryption, vulnerability, access authentication, and authorization processes.
Integration architect	Specializes in enterprise integration aspects, including integration paradigms such as service-oriented architecture, event-driven architecture, messaging, publish-and-subscribe, and the underlying middleware technologies.
Configuration control	Ensures that all changes to enterprise architecture are identified, tracked, monitored, and appropriately documented.
Quality assurance	Makes sure that all established project standards, processes, and practices are followed.
Risk management	Identifies, monitors, and controls risks in enterprise architecture in light of environmental factors and constraints.
Technical editor	Ensures that architecture policies, models, and other documentation within the enterprise architecture repository are clear, concise, usable, and consistent with the configuration management standards.

An architect usually operates at a particular level in the organization (enterprise, program, or project level). The position depends on her proficiency, experience, and seniority.

If needed (typically in large organizational setup), the enterprise architecture effort may be treated as a formal program. In that case, the chief architect is equipped with a dedicated program management office (EA-PMO) for enterprise architecture. The EA-PMO is established specifically to manage and control the development, use, and maintenance of the enterprise architecture. The PMO is tasked with ensuring the success of enterprise architecture as per the stated performance measures while managing the finances and risks involved.

Having formalized an EA organization in the enterprise, the health of EA should be checked periodically. This is essential to assess EA’s progress, effectiveness, and value contribution within the enterprise. The standard means of performing an assessment is to use an EA maturity model. We will cover this topic in Chapter 5, “EA Maturity Models.”

EA team position in the organization structure

In a typical large organization, an enterprise architecture group or even many enterprise architecture groups may be functioning at different places. Figure 3-14 shows potential places where the enterprise architecture group can possibly reside within the corporate structure of such an organization.

Figure 3-14 Typical places for the EA team in an enterprise organization.

Many industry analysts and academic researchers indicate that the most appropriate place for an EA team is under the corporate strategy or any such senior business leadership team (for example, CFO or COO). In that setup, the EA function is intentionally moved outside the IT organization to ensure its independence from IT and to align it better to the business. This position (shown as position 1 in Figure 3-14) gives EA the clout to raise enterprise architecture issues to the highest levels and make decisions based on the best interests of the entire enterprise. However, in practice EA is rarely positioned this way today.

In practice, we predominantly meet the EA group in the direct reporting line to the CIO of corporate IT, as shown by position 2 in Figure 3-14. Corporate IT is typically the IT organization at the highest level, with its own budget and management control. For our subsequent discussions, especially in our Bank4Us example, we presume the positioning of enterprise architecture group to be this way.

It also makes sense to establish an EA group while executing a large, multiyear business transformation program that potentially cuts across multiple business units, product lines, customer segments, or geographic regions of the enterprise. In that case, EA can reside at position 3 in the figure and stays within the purview of that program, with direct reporting to the program director or program management office (PMO).

When the enterprise IT landscape is transformed by a number of ongoing programs and projects, the EA group may be located in the realm of the application development organization (shown as position 4 in Figure 3-14). In this case, it tends to become quite IT development-centric.

When the enterprise requires extensive focus on the run-the-business scenario and an efficient day-to-day business operation, especially in a shared service mode and with a large IT landscape, enterprise architecture is often found at position 5. In this case, the risk for the EA team is to focus too much on IT implementation issues.

Finally, if a business unit of the enterprise carries a large IT estate, it may have its own enterprise architecture, as shown by position 6.

In summary, there is no such thing as the single right place for the EA team in the organization structure. In general, the right placement for EA is the position where it can seek a balanced view on business-IT alignment that is neither too strategic nor too tactical, neither too broad nor too deep.

Developing and enforcing standards and guidelines (EA-5)

Until now we have looked at EA activities that are primarily strategic in nature. They identify why an enterprise needs to change, what it aims to achieve in a stipulated time horizon, and the possible paths of traversal. The outcome of these activities is strategy. The strategy is expressed in terms of business and IT maxims (see EA-1), architecture models (EA-2), and guiding principles plus a roadmap for the envisaged change (EA-3). It provides a long-term direction for the enterprise change.

As we have seen, strategic issues are basically formulated in the boardroom and the CIO’s office. After that the enterprise architect has to bring them down to ground-level execution on the IT shop floor. He has to tell how the architecture should be implemented and by what technologies.

The creation of standards and guidelines helps the EA do that. They offer a crystallization point where vision and strategy take a solid state and concrete shape. For instance, a business maxim stating that The security and privacy of customer information is non-negotiable can be turned into a series of security standards that the enterprise can impose on its projects and IT systems.

Standards and guidelines are also an opportunity to synchronize the day-to-day activities on the ground with the vision and strategy. They can therefore also be looked at as a communication conduit between the boardroom and the staff on the ground, allowing them to communicate strategic decisions and receive feedback.

Standards and Guidelines

Standards and Guidelines: Shifting the EA Focus to Implementation

The standards are essentially the choices and constraints that are directly imposed on the design, development, and deployment of business solutions. The enforcement of standards is intended to meet strategic architectural goals—for instance:

• Addressing enterprise-wide common concerns such as security, integration, and manageability in a consistent manner

• Meeting the service-level expectations such as availability, fault tolerance, performance, and scalability in a cost-effective manner

• Improving productivity in the solution development by encouraging reusability, repeatability, and rationalization

• Ensuring long-term viability of the solution implementation by promoting accessibility, interoperability, supportability, configurability, and extensibility

Taking a top-down approach, the enterprise architect should derive the standards from the upstream business and IT maxims, architecture principles, and industry standards.²¹ But the standards can also evolve bottom-up, as the corollary of the best practices and lessons learned during the projects.

For instance, projects may develop a few common software components during their solution development, supporting common needs such as logging, single sign-on, online payment, connection pooling, and so forth. These components may then be formalized into a set of reusable libraries and frameworks that improve consistency, reliability, and productivity in future projects.

An enterprise architect is a key player here. Being well positioned to have a holistic view of the enterprise, she must be a driving force in identifying common IT needs of the enterprise, formalizing common ways of addressing them, and imposing them as standards for enterprise-wide usage.

Both the top-down and bottom-up approaches carry certain benefits and risks. A top-down approach maintains the big picture but may be plagued with an “ivory tower syndrome” that might result in a blind and futile enforcement of standards. The bottom-up approach, on the other hand, is concrete and pragmatic by nature but may end up in unnecessarily proprietary solutions.

As a consequence, the formalization of standards is a continuous process, combining top-down and bottom-up approaches. The enterprise architect tracks emerging trends, conducts industry research, assesses technologies, and then standardizes the use of such technologies for an enterprise. At the same time, she assimilates experiences from the past projects to establish standards and guidelines for the future projects.

During that process, the enterprise architect always seeks to minimize the number of in-use technologies in order to enhance the manageability of the environment and to deliver a consistent set of IT services. It is a tight rope walk for the architects because it involves balancing the need for consistency in a large-scale system implementation with the need for diversity of solutions demanded by the business. This means in detail:

• Consistency. In a large-scale system environment, consistency in solution implementation is critical. It enables predictability, fosters repeatability, encourages reuse, increases productivity, and improves manageability.

• Diversity. In a dynamic market environment, openness for a diverse set of solution implementations is equally important. It promotes innovation, enables business growth, and offers a competitive edge in the marketplace.

Standards are essentially meant to offer guidance to the project teams in selection and usage of technology while building their business solutions. Likewise, they are also meant to aid the architects in the governance of solution design and implementation in accordance with the target architecture.

Standardizing on technology usage

Technologies emerge and continuously evolve over time. Many technologies come and go, but only a few of them succeed and sustain. One of the fundamental considerations in determining the strategic fit of an application is to look at its underlying technologies. This base needs to be rated in relation to the strategic importance and supportability of those technologies in the overall schema of the enterprise. The overall schema of the enterprise’s technology usage can broadly be classified as shown in Figure 3-15.

Figure 3-15 Technology classification in an enterprise

This classification plots an enterprise’s ability to execute the projects in a given technology on the X-axis and plots the strategic importance of the given technology on the Y-axis. This classification closely relates to the Ward and Peppard scheme, described earlier in the “Evolving the IT Landscape (EA-3)” section. The Ward and Peppard scheme is better suited for application classification, whereas this scheme focuses on the technology layer. Comparing the two schemes leads to the following findings:

• Star and Cash Cow applications will be scattered across the Core and Declining technology areas.

• Wild Cats will be spotted in the Emerging square.

• Poor Dogs can be found anywhere.

Having categorized the technology usage in the enterprise based on the aforementioned classification, one of the primary responsibilities of the enterprise architect is to inform the project teams of acceptable technology usage. This comprises the technology products they can use and the technology standards they must follow while building business solutions:

• Technology products. This comprises any software that is acquired to support an enterprise’s business or IT needs. It includes commercial products, open source, libraries, frameworks, and any other code that the project teams did not create internally.

• Technology standards. This refers to one or more related specifications that have been approved externally by standards development forums, have been widely used and accepted by the industry, have been enforced by the government, or have been internally mandated for use within the enterprise. Standards come in the form of policies, guidelines, constraints, or conformance criteria.

The enterprise architect thus provides guidance on the permissible range of technologies that a project team may select to meet their business requirements. However, the approved technologies are not necessarily equal in terms of their supportability and quality of service. Each technology is subject to certain constraints. It is apparent from Figure 3-15 that supportability depends on the categorization (Core, Declining, Emerging, and Specialized). Opposed to that, the service level depends on business demand and cost structure and can, for instance, be classified as platinum, gold, or silver.

The technology guidance primarily comprises a list of technology products and technology standards that have been assessed and rated to be either compliant or noncompliant with the enterprise’s strategic technology direction. It should therefore cover each and every technology that is relevant to the enterprise—from web browser to data storage; from coding standards to UI guidelines; and from modeling tools to security guidelines. A mature technical architecture is one that fulfills all the following criteria:

• Identifying the key technologies

• Describing the enterprise strategy for technology provision

• Containing a list of vendors, products, and standards associated with the technology

• Including a model for technology implementation

In the best possible case, such standards enable project teams to assemble a significant portion of their solution using the guidance contained in the technical architecture and the list of approved products and standards. The teams should not use forbidden technologies but at the same time should minimize the portion of their own development.

In reference to the technology classification in Figure 3-15, the EA group at Bank4Us does not have dedicated specialists for many Core and Declining technologies within the EA group itself. In general, the competency in some of these technologies—for instance, mainframe or CRM—often resides within the IT delivery units owning those environments. Oscar Salgado, the chief architect leading the EA group of Bank4Us, finds it therefore appropriate that the IT delivery units should be responsible for maintaining the approved product list and standards specifications for their own technology environment.

In addition, Oscar ensures that a single point of contact (SPOC) for the architecture group is appointed from every delivery unit. The SPOC makes sure that appropriate communication between the IT delivery unit and the architecture group is established and ensures a continuous information flow between the two. Oscar does not want his team to be too deeply involved in the Core technology domains belonging to those units. He wants his team to focus only on the edge of those technology islands—on the interaction of the IT delivery units with the rest of the enterprise.

Nevertheless, Oscar also looks for the opportunities for short-term job rotation for his architects. That way, they can participate in ongoing project activities within such independent IT delivery units. The primary role of Oscar’s enterprise architects there is coaching and reviewing projects. This helps them to keep an eye on the end-to-end solution delivery that runs across many of these units.

Oscar takes a similar stance for the Specialized technology space simply because its footprint is too small to attract enterprise-wide attention. It is always the owning organizations who should care for these technologies.

On the other side of the spectrum, generalized technologies such as .Net, JEE, and similar development platforms have widespread proliferation across the bank. Oscar therefore takes over the ownership of them under his EA regime. The EA team offers a crystallization point for these technologies to which the project teams can refer and contribute.

Irrespective of whether a technology is centrally controlled by the EA group or not, Oscar ensures that the approved lists of technology standards and product specifications are maintained by the respective owners and that they are accessible to the EA group and the wider IT community over the bank’s intranet. That way, Oscar’s team has an up-to-date, consolidated list of all the products and standards employed within each technology environment at the bank. Table 3-8 presents a partial view of this list. Such a view is available on the EA Website accessible to all project teams over the Bank4Us intranet.

Table 3-8 Bank4Us Technology Products and Standards List (Partial, to Illustrate the Concept)

As far as the Core, Declining, or Specialized technologies are concerned, the respective IT units in the bank possess a sustainable delivery capability. They are fully equipped with mature product implementations, established standards, and an experienced staff. However, this is not the case with the Emerging technologies and there are large numbers of new technologies shooting up like mushrooms. The bank does not have expertise on these new technologies. It is the EA group’s task to lead the way and harness the bank’s new technologies.

Introducing new architectural paradigms

Looking at the CEO vision, “Best-in- Class Customer Experience: Anywhere, Anytime, Any Channel,” CIO Dave Callaghan has recognized the pressing need for a comprehensive approach for integration within and beyond the bank. Dave has therefore translated the CEO vision into an IT maxim that says:

Our systems must support new ways of doing business collaboratively with our partners and customers—an architecture that allows electronic bonding at more touchpoints and at a depth not previously attempted. The styles of electronic bonding should now include multidevice, service orientation, white labeling as well as the more traditional web portals and B2B gateways.

For Oscar, this need for better integration is further fueled as a consequence of his decision to manage the technology areas in the bank at their edges rather than in their entirety. Since he intends to offer more local autonomy to individual technology owners (the IT delivery units themselves), he needs to ensure stringent control at their edges: their integration and interaction with the rest of the enterprise.

On the ground, Ian Miller, the enterprise architect working on Oscar Salgado’s team, supervises all business projects around Closer to Customer for architectural conformance. It is a regular governance activity that he conducts in addition to his application rationalization mandate. He has recently observed a growing demand from the business side for enabling mobile channels, accessing mainframe data over the Internet, synchronizing customer data across disparate systems, and so forth.

He has briefed the EA group about the need for a mobile platform, integrating to a host of heterogeneous back-end systems in the bank, and using a common integration layer. The EA team has opted for an SOA approach for the proposed integration platform, including the introduction of an enterprise service bus (ESB). However, no one in the current EA group has much insight into SOA. Oscar therefore recruits Shashi Malhotra, an SOA expert, into his team. Shashi joins the team with a mandate for ESB use at the bank. His task lists contains the following activities:

• Provide a base to bed the ESB technology at Bank4Us

• Confirm the approach and understanding of ESB use and implementation

• Establish standards and guidelines for service development and integration

• Act as evangelist for future SOA opportunities at the bank

We will accompany Shashi in rolling out a pilot project on ESB use in the next subsection, “Monitoring the Project Portfolio (EA-6).”

Enforcing standards and guidelines

Skim through any document published by an EA group anywhere in the world and somewhere you will see a notice-cum-guidance-cum-threat that typically says something along these lines:

All projects will be evaluated based on their consistency with the direction, products, and standards specified by the enterprise architecture. The project teams must adhere to the policies and standards stated in the enterprise architecture. Only the use of the listed tools, products, and technologies is permissible. The rare deviations need to be justified.²²

The architects and developers on the ground react to such guidance with a mixed-emotions mindset. Widespread acceptance, subsurface resistance, and outright denial are the predominant reactions.

Let’s look at the widespread acceptance scenario first. This is the best-case scenario, reflecting a positive attitude of project teams toward the standards. They follow the standards not because an authority like EA says they should but because they themselves have come to realize that it is the right thing to do. They have nurtured the standards from the ground up. It has helped them do their job better in the past and will continue to help them in the future. Without doubt there will be pros and cons to any stipulated standards, but there is an overall agreement that they are the right thing. These standards have now seeped into their habit and culture.

For instance, at Bank4Us, the Proactive JEE Infrastructure (PJI) listed in Table 3-11 is widely used. At the time of its introduction, it substantially improved the productivity of project teams in JEE development. This sounds like a dream come true for the enterprise architects.

Unfortunately, developers and architects in the project teams don’t often really feel this way. More often, they show subsurface resistance toward the standards. They are typically frustrated with the constraints that such standards impose on them. Reasons are manifold: The standards and products are outdated, the newest library versions are not available (or approved by EA), the best possible solution for the project turns out to be nonstandard-complaint, and so forth.

At Bank4Us, the aforementioned PJI standard has by now grown into a massive proprietary code base. It costs too much in maintenance, and over the years has lost its significance. It locks the project teams into an outdated version of underlying JEE application server. Many enthusiastic developers and architects complain that they are notoriously late in leveraging the newer standards and rich feature sets, which are readily available in the latest version of JEE platform. They also complain that they cannot reduce the project costs by moving their noncritical applications to an open source platform.

At the extreme end, some project teams show outright denial for standards adoption. This is especially true for the standards enforced on them. Quite often it is not the developers but the project managers who are wary of immature industry standards. Although compliance with industry standards is essential for long-term sustenance, they might not necessarily be ready for primetime use. Sometimes they have been stipulated in the hope of anticipated benefits but without knowing their practicality.

Such decisions may stem from sheer enthusiasm fueled by market hype or the innovativeness of an idea. However, in the absence of concrete proof points, it is a challenge for enterprise architects to convincingly adopt such standards to the mainstream development. Amid tight delivery schedules, inflating project scope, and unanticipated technical glitches, a mandate for such standards is prone to move down to the bottom of a project team’s agenda and then drop off the list.

Such a mixed-emotions mindset—which includes widespread acceptance, subsurface resistance, and outright denial—characterizes the organizational dynamics of the enterprise. If the emotions are leaning more toward the latter two, one could call it organizational inertia. There are two extreme kinds of standards adoption strategy to deal with organizational dynamics:

• Eager adoption. Incubate the emerging industry standards and the cutting-edge technologies right away, and then proactively enforce them in order to become the first mover in the market. This is expensive in terms of development costs simply because it adds to the project effort and risks. It also neglects the opportunity to skip immature versions and reduce the number of upgrades. On the positive side, this strategy might offer a competitive edge and hence be suitable for applications belonging to the Wild Cats categories and for Emerging technologies.

• Reluctant adoption. Defer adoption until as late as possible. This is expensive in the long run if the enterprise has to catch up with the industry at a later point in time. In that case, technology debt will accumulate and a wide software installation base will be in use when the need for adoption arises. This will demand a massive and dedicated migration project later on. However, this adoption strategy generally minimizes the immediate software development costs. This applies especially to the applications belonging to the Poor Dogs category and the technologies in the Core and Declining quadrants.

In practice, the most rational approach will be a tightrope walk between these two extremes. In mature EA organizations, interim project reviews provide a mechanism whereby a formal dialogue between the enterprise architects and project teams is established. In that case, a golden mean between the two extremes—eagerness and reluctance—is reached by consensus.

The first interim review, called an architectural conformance review (ACR), is conducted during the design phase of the project. It must be concluded before the development phase can begin. The ACR allows project teams to consult with enterprise architects and validate the conformance of their solution design against the prescribed standards.

The second interim review is called a post-implementation review (PIR). It takes place after each production deployment and allows enterprise architects, along with other project stakeholders, to reflect on the performance of the project in regard to their specific interests and concerns. We will outline both ACR and PIR processes in the next section, “Monitoring the Project Portfolio (EA-6).”

Standards Enforcement Styles

Extreme Enforcement of Standards

At Amazon, SOA standards are known to be nonnegotiable. Google engineer Steve Yegge tells the story of Amazon’s rather ruthless style of enforcing SOA standards (2011).²³ In around 2002, Jeff Bezos (Amazon’s CEO) issued his mandate for SOA:

The project teams must expose their data and functionality through service interfaces only and they must communicate with each other through these interfaces only.

Bezos then mentioned:

Anyone who doesn’t do this will be fired.

What Bezos said was meant that way; it expressed his conviction for the SOA in no-nonsense terms. Amazon has made lots of progress since the SOA mandate was given in 2002, and it will have learned a lot of new lessons on the way. The infrastructure they had built for selling books has now transformed into an externally accessible, extensible computing platform.

However, this is an exceptional case. It is not apt to follow this style of enforcement in typical large enterprises. The statement is meant to set the long-term direction. In Chapter 9, where we discuss strategies of how to change the direction of EA in an enterprise, we will refer back to this story as an example for style called Black and White Goals.

One needs to be aware that this is a double-edged sword. If enforced strictly, such a statement will take away an open, creative, and risk-taking culture. If not enforced strictly, it becomes a mockery. Nevertheless, the morale of this story is: A mandate for standardization has a chance to succeed when it comes from the highest authority and it comes with a strong sense of urgency and conviction.

At Bank4Us Oscar Salgado, the chief architect, takes a balanced view and has established the following architectural principle: “Standardize wherever possible, deviate wherever necessary.” His rationale behind this principle is that 100% standardization is not possible and not needed. The effort of his team, however, must be focused on improving the level of standardization, progressively and definitively.

Monitoring the project portfolio (EA-6)

Project portfolio management begins with portfolio planning—normally a yearly exercise spinning off from activity EA-1, “Defining the IT Strategy.” Portfolio planning takes up the input from the IT strategy—business and IT demands, current gaps, maxims, and high-level strategic initiatives—and translates it into work packages for projects. The program managers, under the stewardship of the CIO, fiercely engage in defining, prioritizing, and estimating IT projects.

What is a portfolio? A portfolio refers to an abstract collection of programs and projects gathered for management convenience. The constituents do not necessarily have a common business theme. The main purpose of the portfolio is creating value and maximizing return on investment.

A program, on the other hand, is a collection of projects sharing a common business case or objective. It is meant to realize business benefits defined by the business case. In both cases, a project is a temporary endeavor to accomplish a prescribed unit of work, usually constrained by timeframe, budget, and deliverables. For the sake of brevity, key elements of portfolio, program, and project are summarized in Table 3-9.

Table 3-9 IT Project Portfolio Management: A Summarized View

It may be noted that the management attention and approach in portfolio management starkly differ from the traditional way of running projects. Without portfolio management, once a project has been funded its business value is normally not reexamined again. The monitoring focus is only on key metrics, such as quality, schedule, and scope. With portfolio management, however, you review the portfolio periodically—typically quarterly—and you question each project: “Does this project still make sense?”

If it does not, you take corrective action. The projects are viewed in relation to one another, not as a stand-alone venture in isolation. This approach allows balancing the projects in the portfolio: High-risk projects are complemented by safe projects, short-term by long-term ones. One should continuously rebalance the portfolio to maximize the value and optimize the return on investment. The principles and approaches employed here are essentially those applied to managing a financial portfolio.

IT portfolio management indeed stems from the concepts in financial portfolio management, whereas EA has its roots in architecture and technology. The two are separate disciplines and carry different genes. Yet they must be fully integrated with each other, as both have a common goal: Evolve the enterprise IT landscape in a strategic direction to maximize benefit realization in the long run. In the process, both practice areas attempt to take organizational politics out of IT investment decisions.

Building the project portfolio

Let’s chalk out a rough sketch of the strategic planning process in an enterprise. It begins with the strategy formulation, wherein business units within the enterprise engage in preparing their business plans. They derive their business strategy based on the CEO’s mandate and the implied business maxims. Then they identify the business initiatives they will undertake and prepare a time-bound business plan to implement their strategy. Earlier in EA-1, “Defining IT Strategy”, we had a cursory look at how this happens in a car manufacturer example, Car4Us.

Figure 3-16 depicts an illustrative portfolio planning process. One of the primary inputs to this process is the collection of business plans coming from all business units. Each business plan identifies the gaps in the enterprise’s IT landscape that need to be bridged for the respective business unit so that it can meet its business objectives. These gaps can broadly be classified as functional gaps and technology gaps. The functional gaps are translated into business needs. The technology gaps are translated into IT needs. These business and IT needs form the basis for identifying and defining IT initiatives or projects.²⁴

Figure 3-16 An example to illustrate the concept of a portfolio-planning process.

At this stage, the needs are stated at high level only, sufficient enough to scope the IT initiatives and gauge the order of magnitude for each initiative. This helps arrive at a ballpark cost estimate for each initiative. Evidently this exercise calls for deep insight into the enterprise that only the experienced program managers and seasoned architects there can bring to the table. For that reason, the Portfolio Steering Committee at Bank4Us is composed of Dave Callaghan, the CIO as the chairperson, and senior program managers. Chief architect Oscar Salgado is invited along as a member as well.

In general, enterprise architects are not accountable for portfolio planning. It is the business units that drive the CIO’s agenda. Nevertheless, enterprise architects play an important part in it. Acting as an assessor or an advisor, enterprise architects are well positioned and fully equipped to perform the following activities:

• Identifying and consolidating common IT needs across the business units

• Seeking opportunities to introduce IT-focused initiatives into the portfolio

• Prioritizing projects based on benefit potential, architectural fit, and implementation risks

With day-to-day exposure to the activities in EA-1 through EA-8, enterprise architects know what the enterprise does, how it works, and how it behaves. This insight can make them influential personalities in the portfolio planning process. In Bank4Us, Oscar, the chief architect, is a member of the Portfolio Steering Committee for the very same role—as an advisor and as an assessor.

Pushing IT-focused effort into the portfolio

IT-focused effort comprises any activities that do not stem from a qualified business case or do not enjoy business sponsorship. Yet this effort is needed, if only to ensure better IT management. It comes in different flavors: migration, consolidation, decomposition, reengineering, replacement, or retirement of existing applications (or technologies, or infrastructure). It may as well be for incubation of new technologies in the enterprise: concept creation, technology research, prototyping, and piloting.

The goal of an IT-focused effort is to help the evolution of the IT landscape toward the target state architecture. Hence, as depicted in Figure 3-16, it usually falls under the premise of EA. In the absence of direct business sponsorship, enterprise architects have to find some way to add such IT-focused effort to the project portfolio. There are two ways this can happen:

• Dedicated approach. The venture is executed as a separately funded project, often referred to as an infrastructural project. Normally the investments come from the CIO’s own IT budget.

• Opportunistic approach. In this case, the initiative is included in the business-sponsored projects that are required as a result of new business requirements or major enhancements.

Let’s again turn back to Bank4Us to see how this can happen there.

Ian Miller, the enterprise architect in charge of an application rationalization program, is looking at downsizing the legacy environment, for which he takes a deep dive into the bank’s current IT landscape and identifies rationalization opportunities. He uses the practices and techniques outlined in EA-3, Evolving the IT Landscape, to do that. He and his team have defined a series of work packages for the rationalization effort and now prepare the rationalization roadmap along with supporting cost/benefit analysis.

Oscar Salgado, the chief architect, is convinced that there are tangible rationalization targets that they must chase in the near future. However, the rationalization effort involves many, many stakeholders. It demands explicit and impartial funding—essentially to avoid any bias toward a particular business unit. Therefore, Oscar has taken the dedicated approach and seeks centralized funding from the CIO’s budget. He therefore catalogues all rationalization proposals in the current year for CIO sponsorship.

In parallel, Oscar has observed that many business units, in their business plans, consistently express a need for mobile applications. These applications would help them interact more closely with their customers. Oscar has recognized a need for a common mobility platform and a need for better integration capabilities that can seamlessly integrate the mobility platform into the bank’s IT backbone. The top two priorities for the business are ease of integration and real-time access to information.

Oscar acknowledges that the current IT landscape lacks these critical capabilities in a big way. Hence, mobility and integration are on his radar during this year. As described in the previous section, “Developing and Enforcing Standards and Guidelines (EA-5),” he plans to pilot an enterprise service bus (ESB) as part of a more complete approach to integration at the bank. For that reason, he has recruited the SOA expert Shashi Malhotra onto his EA team to start working on the ESB mandate.

The stories of disillusionment with earlier attempts at enterprise application integration (EAI) are not yet forgotten at the bank. Oscar is cautious about the widespread skepticism toward and lack of experience in SOA. He prefers an opportunistic approach for the ESB deployment. Therefore, he instructs Shashi to set up an ESB infrastructure that can implement real-life integration scenarios at the bank. This infrastructure must demonstrate the applicability of SOA to the bank’s needs and address the integration needs and pain points of the business. This is a better way of getting the funding, and it will also keep the pilot effort relevant to the business.

Shashi consults with the program managers and their business counterparts. They work closely to come up with a list of integration scenarios in their projects that can be potential candidates for piloting. There are 14 of them. Shashi now needs to evaluate them and shortlist the most appropriate ones for his pilot project. To that effect, he prepares a questionnaire and seeks information about these integration scenarios from concerned business and IT experts. Shashi’s weighted scoring of the integration scenarios yields the scorecard depicted in Table 3-10. This scorecard helps him shortlist 4 out of 14 scenarios for his pilot project.

Table 3-10 Defining and Scoping an IT-Focused Pilot Project (ESB Deployment)

The pilot project has now been scoped; it covers typical integration requirements for the bank. As the next step, Shashi needs to come up with two things: ballpark cost estimates (how much product vendors and implementers will charge) and a fallback strategy (how to back out without risking the project if the ESB does not perform its job).

Oscar finds Shashi’s approach sensible, practical, and safe. They now need to convince the respective program managers to apportion the ESB cost into their project estimates and be the first movers for ESB technologies at the bank.

Prioritizing the projects

Looking back at Figure 3-13, you find many IT initiatives being identified to fulfill the IT needs of business units. These initiatives need to be prioritized, shortlisted, and then budgeted as projects for execution. To prioritize them, three things are needed: a list of initiatives, the criteria for prioritization, and most important, the right set of people to participate in the prioritization process.

The first step in the prioritization process is to define what constitutes a project and to enforce this definition so that the projects can be compared on equal footing. This can be done easily by mandating a standardized statement of work or project charter template.

The next step is to provide a consistent framework for prioritization. It must allow assessing all projects with an impartial eye. It should be based on predefined criteria, such as value contribution, strategic fit, implementation risks, cost, and so forth. The criteria depend on the enterprise and its market outlook, business priorities, and organizational constraints. Yet generic prioritization criteria are worth mentioning: They may act as a springboard to establish a tailor-made prioritization scheme for a specific enterprise. The parameters are as follows:

• Value contribution. This parameter expresses the business value the project aims to deliver. Is it meant to reduce expenses, increase revenue, contribute to competitiveness of the company, or serve regulatory compliance? Is the benefit quantifiable?

• Strategic fit. This parameter recognizes if the project is taking the enterprise in the strategic direction. Is this project serving the strategic intent of the enterprise, whatever that may be—for instance, be a first mover, be an early follower, enhance brand value, or improve market penetration?

• Cross-LOB²⁵ ranking. This criterion looks at the cross-organizational impact of the project. Who is the sponsoring business unit, and how relevant is this project for other business units and to the enterprise as a whole?

• Implementation risks. This value measures the deployment feasibility, ease of implementation, or probability of success. Is the enterprise really capable of executing this project?

• Integration complexity. This parameter assesses the level of interdependencies and integration requirements stemming from this project. How well are the upstream and downstream dependencies in the project managed? How easy it is to seamlessly integrate the project implementation into the enterprise’s IT landscape?

• Cost. This criterion gauges whether the cost estimates are in the permissible range for business acceptance and in line with the anticipated value contribution of the project. Are the costs justifiable and within sound limits?

These criteria are to some extent interrelated. For instance, high-value projects are normally big; they bear high costs and high risks. As a consequence, the entry barrier for high-value projects is also quite high. One such big project causes more damage when it fails than 10 small ones.

The criteria we’ve outlined are generic and can be further extended or drilled down as needed. However, most of the criteria are not really quantifiable and cannot be objectively assessed. At best, one can do the rating on a scale of 1 to 10. As a result, the prioritization process requires tacit knowledge of the enterprise. The steering committee, comprising program managers and chaired by the CIO, typically brings that knowledge to the table. The same steering committee also serves as the decision authority.

The third step is the prioritization process itself. The steering committee prioritizes the projects under the known organizational constraints such as available funds, sourcing capacity, project interdependencies, and so forth. The process involves a what-if analysis on multiple portfolio scenarios, adjustment to parameters and constraints in the portfolio, and simulating and assessing alternatives. The goal is to determine the optimal allocation of investments to initiatives and projects. It follows pretty much the same approach that is employed in financial portfolio analysis.

The output of the prioritization process, among other things, comprises:

• An investment matrix that shows which programs get investments (along the rows) and from which source (along the columns)

• An integrated release plan that shows broad timelines for the IT initiatives, with critical interdependencies and constraints highlighted

• A feedback loop into the business units

The project prioritization does not have a closed-form solution. It is a constrained optimization process that involves many parameters and is fairly complex. As the size of a portfolio grows, prioritization gets overwhelmingly complex, and a simple spreadsheet-based assessment becomes futile. Beyond this point, the use of a more sophisticated portfolio management tool does make sense. Taking a deep dive into the portfolio analysis process is beyond the scope of this book. Interested readers can refer to the literature available on the subject of IT portfolio management.²⁶

Auditing the portfolio

Once the projects have been planned and funded, they move into delivery mode. The project teams are formed and the work begins. The focus is to deliver software features in accordance with the defined scope, specifications, and timeline. Formal management control is in place to ensure that the project delivers what has been committed to.

While the short-term goals of the business are being met by the projects, enterprise architects need to guard the enterprise IT landscape. They have to ensure that solutions are designed and implemented in view of the long-term goals of the enterprise and in alignment with the envisaged target state. Although enterprise architects should not be involved too deeply in the day-to-day project execution, they need to keep an eye on the projects, especially during design, acceptance, and deployment phases.

In more mature EA organization, this is done by a formalized portfolio governance. The role of portfolio governance is to provide a decision-making framework that is logical, robust, and repeatable to govern project investments. Figure 3-17 depicts an enterprise architect’s viewpoint on portfolio governance. It typically comprises two formal review processes: an architecture conformance review and a post-implementation review.

Figure 3-17 An example to illustrate the concept of a portfolio governance process.

These processes act as tollgates for every project delivery that enters the enterprise’s IT landscape. Ross (2005) identifies the post-implementation review as one of the essential management practices for mature EA organizations. In the next section we will go through the architecture conformance and post-implementation reviews.

Patrolling for architecture conformance

The earliest entry of enterprise architects into a project may happen at the time of the project kickoff. It is the time to gain a first-cut understanding of the business requirements and to recommend the technology prerogatives for solution implementation. This involvement is, however, restricted to an advisory role.

A more formal engagement of enterprise architects in the projects usually begins during the design phase, primarily for review of the proposed solution design for conformance against the stipulated architectural principles and standards. This engagement instills a governance mechanism. This mechanism enables project teams, in consultation with the enterprise architect, to confirm the alignment of their solution design with the enterprise architecture, its policies, its technology roadmap, and its technology portfolio.

What does an enterprise architect need to review the solution designs for? There is no standard list of parameters on which such a review can be based. Again, it pretty much depends on the priorities and constraints of the enterprise. Nevertheless, the criteria listed in Table 3-11 give an idea of an enterprise architect’s possible architectural concerns during the design reviews.

Table 3-11 Architecture Conformance Criteria (An Example to Illustrate the Concept)

Criteria	Metrics
Technology usage	• Standards compliance, justification for deviation • Infrastructure reuse, shared services—productivity gain, effort, and cost savings
Capability completeness	• Business scope completeness—count and/or percentage of: customer types supported, product types supported, processes supported • Technical implementation completeness—count and/or percentage of: correct implementations, correct interface exposures, operations supported
Capability reuse	• Percentage of installed base (migrated to use common IT capability or shared services) • Percentage of user base (migrated to use common IT capability or shared services)
System shutdown	• Systems shutdown variance—actual vs. target (expressed in terms of count or percentage)
Integration complexity	• Integration complexity • Integration maturity index: Using CMM for integration • Level of process standardization achieved in percentage (across lines of business/product-portfolio/geographies): Actual vs. target
Process harmonization	• Process cycle-time reduction • Process failure reduction: Failure mode and effect analysis (right-first-time)
Data quality	• Timeliness, accessibility, completeness, and correctness (accuracy and integrity) of data in given business context • Data ownership, consolidation, synchronization, reuse, and sharing

As shown in Figure 3-17,²⁷ the architecture conformance review begins with a registration. The project team registers its solution design for architecture review to a governing body. TOGAF (The Open Group, 2011) identifies such a governance body as Architecture Review Board (ARB). The registration is needed to plan ahead the engagement of the project teams with the ARB during the upcoming delivery cycle. It helps them identify the design artifacts they want to put through the review process. It also chalks out the plan as to who, when, how, and on what criteria the reviews will be conducted.

It is expected that all the project teams register their solution designs for review by enterprise architects. It is, however, at the discretion of enterprise architects to determine which solution designs demand a formal review and which ones do not. Usually the enterprise architects need to focus their efforts on architecturally challenging areas in the enterprise.

Wherever practicable, the enterprise architect may recommend that the project architects themselves perform the review of their solution design and claim the self-certification for conformance. The enterprise architect can then determine whether such self-certification is justified, depending on the evidence produced by the project architect plus any other background factors such as the strategic importance of the solution and the track record of the project team. This minimizes the overhead for everyone.

We will explore new and effective ways of achieving this goal using the architecture scrum in Chapter 7, “Building Block 2: Involve All Stakeholders by Interlocking Architecture Scrums.” These scrums enforce strong rules for timeliness and quality and facilitate regular interaction and communication.

In essence there are two routes to certification for architecture conformance: self-assessment or a formal architecture conformance review. In either case, conformance certification must be sought by the project team before the solution design is finalized and the development begins. In some cases, the enterprise architect may grant a conditional certification, requiring the project teams to take corrective action to close the identified nonconformities prior to solution deployment.

After certification, if the project team makes any material change to the solution design, it must pass through the review process again. A material change is any change that invalidates the basis on which earlier conformance certification was granted. The enterprise architect comes back into the picture again during the acceptance testing phase. There the enterprise architect has to revalidate whether the solution being deployed is indeed architecturally conformant at that stage.

This is an idealistic sketch for an architectural governance process. In practice, we find project teams invariably fail to comply in many different ways and request exceptions. The most commonly encountered reasons are:

• Tight project timelines

• “Scope creep”

• Inadequacy of architecture

• Specificity of business requirements that cannot be fulfilled with the standard architecture as stipulated by the enterprise architects

• Open issues in the stipulated architecture itself

Some reasons are genuine, whereas some are mere excuses. What do enterprise architects do then?

1. Grant a conditional certification, telling the project team to close the nonconformity at the earliest possible project milestone in the future, or

2. Place a red mark on its status report to the steering committee, essentially escalating the nonconformance of the project higher up

In the first case, the project team may agree to take all possible corrective actions and the enterprise architect may also take a softer stand. They compromise and make a deal. But later the project team either gets dismantled due to the project closure or it demands additional funds or time for making post facto changes in design and deployment. It is quite unlikely that additional funds will simply be granted for the sake of architectural compliance.

In the second case, the enterprise architect is bound to meet resistance in escalating nonconformance to the steering committee. However, she rarely has a really strong case to make the steering committee act in her favor. This is especially true when the solution has already been implemented by the project team and is working as intended in the production environment.

So, neither compromise nor confrontation works well. It is therefore of utmost importance for an enterprise architect to convincingly negotiate. He needs to create a win-win situation for both parties rather than falling into the trap of argumentative discussions. It is a real test to measure the enterprise architect’s interpersonal skills.

In Bank4Us, the enterprise architects assess solution designs by conducting formal architecture reviews. Oscar Salgado, the chief architect, reports a consolidated architecture conformance report to the steering committee at the end of each 90-day delivery cycle. The report is a dashboard, as shown in Table 3-12, intended to be discussed during the post-implementation review.

Table 3-12 Architecture Conformance Success Scorecard (An Example to Illustrate the Concept)

Taking a collective view of portfolio performance

The post-implementation review is a process (see Figure 3-17) by which the steering committee takes a collective view of the portfolio performance at the end of each delivery cycle—typically a 90-day release cycle. In addition to the steering committee, this review may seek participation from other stakeholders, such as business sponsors, program managers, and enterprise architects. Each stakeholder has different concerns and motives to judge the success or failure of a project.

Apart from the architecture conformance discussed earlier, delivery assurance and organizational readiness are the other two predominant management concerns in the post-implementation review (Table 3-13).

Table 3-13 Post-Implementation Review Criteria (For Illustration Only)

The essence of post-implementation reviews is that the performance and outcome of all the projects are viewed in comparison with each other, not in isolation. This allows to assess the overall portfolio performance more often (for instance, once every quarter). A consolidated performance dashboard reported at the portfolio level on a quarterly basis is a powerful management tool. It offers a number of strategic levers to the CIO, supporting the following activities:

• Adjusting the priorities and investments rapidly in response to the business flux

• Balancing the project pressure and change impact among different departments

• Assessing the strategic value of projects that have a seemingly low ROI

• Providing feedback on strategic decisions back to the business more frequently

Making it a two-way dialogue

Both architecture conformance and post-implementation reviews are opportunities for an enterprise architect to engage closely with project teams. On one hand, they allow the enterprise architect to guide the development effort and ensure that project teams conform to the strategic direction. On the other hand, they help her backfill the enterprise architecture by consciously gathering and assimilating the best practices and lessons learned in real-life projects.

EA begins with conceptualization, idea generation, and philosophical preaching, but it gains substance only after gathering practical revelations from the projects on the ground. Hence these review processes can well be seen as mechanisms to backfill the enterprise architecture. They should enable two-way communication between the enterprise architecture and the project teams—guiding but also learning, governing but also getting feedback. We will discuss additional, innovative ways to do that in both Chapter 7, “Toward Pragmatism: Lean and Agile EA,” and Chapter 8, “Inviting to Participation.”

Leading or coaching projects (EA-7)

A computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are, in short, a dangerously perfect match.

—Bill Bryson²⁸

A software architect who is not in touch with the evolving source code of the product is out of touch with reality.

—Craig Larman and Bas Vodde²⁹

Sometimes the enterprise architect needs to leave her large-scale drawing board and become involved in a project or program in a technical leadership role. There are several possible reasons for such an assignment:

• A project has been identified as carrying high risk from an EA perspective (a new and unfamiliar technology, a critical business process, a new implementation partner, a project reaching across several business lines, and so forth).

• Higher management has issued a request for a high-profile “technical watchdog” to supervise a strategically important project with board-level attention.

• A project has been triggered by the EA organization itself (like the ESB pilot project in our Bank4Us example in activity EA-6); in that case, the EA team will want to micro-manage the solution architecture.

• An enterprise architect adopts a mentoring role for a junior architect as a personal development measure.

The standard books on EA do not cover this particular aspect of an enterprise architect’s work. Malicious tongues could assume that this is due to EA’s elitist self-conception; however, the more likely explanation is that an enterprise architect in a project or program faces the same challenges as a “normal” project architect. This is certainly true to an extent.

As a software architect, one frequently encounters the notion that a good specification or model speaks for itself—just like a religious icon that gives its blessing to the developers all by itself, by the sheer force of wisdom. This, of course, is nonsense. During a project’s development phase, the architect proactively needs to make sure that her design is actually implemented.

The two quotes at the beginning of this section describe the tightrope walk for the architect in this situation. On one hand, she needs to keep a certain mental distance from the development team. As a technical leader, the architect needs to look carefully at what the developers make of his specification; she must prevent the developers being carried away by technology enthusiasm or “gold-plating” tendencies.

On the other hand, the architect has to be deeply involved in the development work herself. Otherwise, she does not know what is going on and, even worse, how suitable her design is. She needs to get his hands dirty; the lean and agile community calls this an all-hands-on-deck mindset (Coplien and Bjørnvig, 2010, p. 2). Without this mindset, the developers will mock the architect as a mere PowerPoint jockey who excels in drawing pictures with no relation to reality.

Any project architect needs to master this balance of proximity and distance to the developers. On top of that, an enterprise architect has to meet special challenges, when she assumes a technical leadership position in a project or program.

Depending on the project context, the enterprise architect can be perceived as savior, intruder, or wisenheimer from the top floor. She cannot completely avoid that perception, but she can influence it. Her best weapons for overcoming preconceptions are a hands-on mindset, as described, and an open communication style without a know-it-all attitude. “If ‘Communication Is King,’ then clarity and leadership are its humble servants,” writes Mark King (Monson-Haefel, 2009, p. 9).

Another challenge might be harder to handle. There is a natural conflict of interest between a project architect and a member of the EA team. The best and easiest solutions for the project do not always match the “big picture” pursued by EA. This makes the enterprise architect a servant of two masters. Typical conflicts include:

• Use of nonstandard frameworks or libraries, which might save the project a lot of effort but is an unwelcome standard violation from EA point of view

• Extension of the project scope to accommodate a general EA target—for instance, the provision of service interfaces, which increases the project effort and risk

• Different time horizons in technical planning—short-term, milestone-oriented project planning versus a long-term strategic EA vision

The enterprise architect must not overemphasize the global perspective and attempt to build the enterprise’s universal IT solution with a single project. On the other hand, she cannot ignore the big picture, either, and turn a blind eye to development of the larger IT landscape.

There is no patent answer to these challenges. The enterprise architect must make do with professional experience and common sense. As part of a project architecture group, the enterprise architect is the key person to ensure proper judgment on a number of difficult and subtle design decisions. This ability can be expressed by a number of “distinguish X from Y” issues in the design process. Each of them carries the aforementioned dilemma (project versus EA focus) in its genes.

• Distinguish nonstandard solutions justified by project needs from sheer technology enthusiasm and flippant design decisions

• Distinguish investing justified effort into the design phase (for instance, on careful interface design, taking up requirements of surrounding systems such as connectivity and performance), from modeling as an end in itself and death by analysis paralysis

• Distinguish unavoidable domain complexity (which can only be attenuated by skillful requirements engineering) from solution complexity as an indicator of design soundness (as simple as possible, as complex as needed)

Leading other architects in these decisions and coaching them to judge for themselves are essential parts of the enterprise architect’s activity in such a project. In turn, the enterprise architect can benefit from the deep technical expertise in specific technology areas that project architects and developers will bring to the table. Usually more of a technical generalist herself, the enterprise architect should actively involve herself in technical project issues, such as a performance problem due to thread contention somewhere in the server-side Java code. It is a chance for her to gain new insight into common problems as well as to better understand the risks of certain technologies and design patterns.

“There is no ‘I’ in architecture,” says Dave Quick (Monson-Haefel, 2009, p. 54). Architects—enterprise architects in particular—need to be team players, share their knowledge, constantly check the quality of their own work, and distinguish factual from personal criticism. A good enterprise architect is not a solo artist—maybe the first violinist but always an orchestra musician.

Managing risks involved in IT (EA-8)

Enterprises are exposed to a wide range of risks. Bank4Us, for instance, has subdivided the whole range of risks it can fall victim to into several categories, as shown in Figure 3-18.

Figure 3-18 Typical risk categories of a financial institution.

The palette of threats ranges from strategic risks (for example, outsourcing a business unit that turns out to be a competitive differentiator) over environmental risks (political changes or natural disasters) to regulatory risks—the peril of accidentally violating laws or regulations.

Since IT is involved in almost all enterprise activities, it also has its share in all risk categories. On one hand, existing risk scenarios affect IT. A fire, for example, might destroy not only office documents and furniture but also a mail server handling the messages of a wider region. On the other hand, IT also adds new risk scenarios, such as the threat of a denial-of-service (DoS) attack on an online brokerage portal.

Nevertheless, IT risks must not be considered as a new, separate risk category. “IT risk is business risk” write the authors of the ISACA³⁰ Risk IT – framework for risk management (2009). The bad thing about the denial of service attack obviously is not that some web server goes down, but the financial loss and the damage of reputation caused by the outage of the trading site.

Yet from a chief IT mechanics perspective, damages of the IT landscape sometimes look different from the business point of view. What appears as an IT catastrophe—for instance, the irreparable crash of a complete server cluster—sometimes has only a negligible impact on the business figures. Unfortunately this statement also applies in the other direction: Tiny IT bugs can trap the regulatory reporting of a financial institute and cause a penalty in the double-digit million-dollar range. One of the major principles of Risk IT is, therefore, to bind IT risks to business objectives and to evaluate risks in business currency, not in IT currency.

Enterprise architecture is a key to a business-oriented management of IT risks that adheres to this principle. A well-maintained EA model captures the linkage between business and IT and hence facilitates the tracking of IT effects on the business. Figure 3-19 provides an example of how an EA model helps bind IT risks to business objectives.

Figure 3-19 Tracking a business objective down to IT infrastructure.

Bank4Us offers a product called raw material trading access. Customers who subscribe to this offering can trade raw materials such as coal, silver, or cotton with the help of an agent in the local branch office. The local agent places orders to the NYMEX³¹ trading place by using the branch office trading portal application.

The outage of the order placement process initiated by this portal has a clear price tag assigned to it: Given the average daily trading volume, an outage of one hour causes a loss of US$160,000, not counting compensations for lost trading opportunities and the somewhat intangible loss of trust and reputation.

Given these considerable costs, the risk managers at Bank4Us are interested in tracking down what failures in IT can actually cause such an outage. The ArchiMate EA model shown in Figure 3-19 helps solve this puzzle. By following the dependencies, the risk hunters find that the availability of the order process depends, for example, on the functioning of the CICS External Call Interface (ECI) hosted on a particular mainframe computer.

Although this is a simplified example, it makes clear the key role of EA in risk management. It bridges the layers and provides the knowledge base for a business-oriented impact assessment. Typical questions EA helps answer are:

• What business processes are affected if the JBoss server cluster Y2 goes down, and in what state?

• Which organizational units will be cut off from messaging if mail server DUCLONM01 goes down?

• Can damage of router 192.8.56.287 cause an outage on some business service, and if so, what is the expected financial loss?

Enterprise architects are not accountable for IT risk management. This usually is in the hands of the CIO or some senior management board. Yet, according to COBIT, they are at least partly responsible for identifying risk scenarios, assessing their impact, and defining suitable risk responses (ISACA, 2007, p.65).

While participating in activity EA-1, Defining the IT Strategy, enterprise architects also are at least informed about the risk management policy. This policy sets out how big the risk appetite and tolerance of the enterprise is. Is it a risk-averse, conservative firm investing heavily in avoiding bad surprises and mitigating their impact? Or is it an opportunity-seeking organization with a relaxed attitude toward losses and deviations?

Since the protection against risk doesn’t come free, this question needs a well-considered answer. The policy also defines the responsibilities and communication channels with regard to managing risks and thereby forms what the risk IT framework calls risk governance (ISACA, 2009). According to ISACA, IT risks can occur in three subdomains (ISACA, 2009, p. 11):

• IT benefit/value enablement risks. These are risks causing a suboptimal exploitation of IT assets or missed opportunities in business enablement.

• IT program and project delivery risks. These are the usual project risks involved in the prosecution of IT initiatives.

• IT operations and service delivery risks. These are the risks involved in running the IT infrastructure and delivering IT services to the enterprise.

EA has its share in all subdomains. With its focus on business-IT alignment, EA can be regarded as a general antidote against benefit/value enablement risks. Enterprise architects are also consulted in managing the risks of IT projects. In some cases, they even take the driver’s seat in such initiatives, as described in the section “Monitoring the Project Portfolio (EA-6).” Finally, they are at least partly in charge of identifying risks hidden in the current IT landscape—as outlined in the examples—and to accommodate suitable risk responses in the future target landscape.

There are four general types of possible risk responses:

• Avoidance of risks. This means erecting a protective barrier that makes the occurrence of the risk event impossible. But waterproof barriers in most cases are quite expensive or even technically impossible.

• Reduction and mitigation of risks. This entails lowering the frequency of risk events, absorbing the impact of these events, or installing an early warning system.

• Sharing or transferring risks. Insurance policies, partnering, or outsourcing are typical means to get rid of the full burden of a risk.

• Accepting risks. This means to consciously accept the risk and take no action to decrease its probability or impact.

The mindset of an IT mechanic sometimes is inclined to the reduction and mitigation of risks and neglects the other risk responses as viable alternatives.

When dealing with risks, one needs to clearly differentiate between risks and uncertainty. The Factor Analysis for Information Risk (FAIR) framework gives the following formal definition of a risk (Jones, 2005):

[Risk is] the probable frequency and magnitude of a future loss.

According to FAIR’s taxonomy, a risk basically consists of two constituents, namely:

• Loss event frequency (LEF). This measures how often a threat agent (for instance, a hacker, but also a thunderstorm) comes across the asset, how probable it is that the agent attacks the asset in such a case and how vulnerable the asset actually is (how well it resists the attack).

• Probable loss magnitude (PLM). A measure for different kinds of losses, ranging from costs for replacing a damaged asset or diminished competitive advantages to legal fines and judgments.

According to this definition, a risk is always bound to a well-defined event and has known consequences. The probabilities in LEF and PLM can have a wide or narrow confidence interval, but otherwise they are well-known factors of the risk estimation.

Risk responses therefore can be planned. Uncertainty prevails, on the other hand, in case there is an overall lack of knowledge about the constituents or factors involved in a situation. There is no use in planning responses, because it is widely unclear what to respond to. The only reasonable plan of action is to approach the land of the unknown in an iterative trial-and-error approach. Many of the so-called “risks” in IT actually are uncertainties, and the approaches to tackle them are different from those in risk management. Agile software development, for instance, is an example of such an approach.

¹ This scenario is derived from a real case example the authors encountered in one of their client projects.

² See, for instance, the IEEE 1471 standard that defines a meta-model for architecture descriptions (IEEE 2000).

³ BPMN stands for business process modeling notation and is an OMG modeling standard for capturing business processes.

⁴ Adapted from Lankhorst (2009).

⁵ We are referring to the version available at the time of writing, which is version 1.0. Version 2.0 is scheduled for approval by the Board of the Open Group in February 2012.

⁶ http://archi.cetis.ac.uk/index.html.

⁷ Cited from Christian Morgenstern’s poem “The Impossible Fact”:

And he comes to the conclusion:

His mishap was an illusion,

for, he reasons pointedly,

that which must not, cannot be

Palmström, the protagonist of Morgenstern’s poem, was run over in traffic. After recovering, he brooded over how this could happen to him and started studying legal texts. But since law forbade the accident to which he fell victim, he came to the hare-brained conclusion stated and continued his life as a happy bunny.

⁸ Computer-aided software engineering, a tool supporting complex software design tasks.

⁹ Configuration management database, an information repository for the components of an information system.

¹⁰ EAR stands for enterprise archive and is the deployment unit to an application server in the Java world.

¹¹ The notion of a key performance indicator is much wider than application performance in the sense of response times or throughput. It is a general notion for a measure of how well a certain entity performs a task and is used in many areas, such as economics or manufacturing.

¹² Adapted from Winter (2006)… and used with Robert Winter’s kind permission.

¹³ Adapted from Ward and Peppard (2003).

¹⁴ Peter F. Drucker (1909–2005) was an influental US economist and one of the intellectual giants in management theory.

¹⁵ WS-* stands for the body of standards defined by the Organization for the Advancement of Structured Information Standards (OASIS). This is a broad set of standards defining various aspects of Web services such as protocol binding, security, or routing. The implementation of such Web services mostly uses SOAP and either http/https or asynchronous messages. WS-* nowadays is a label for the heavyweight Web services that best fit the internal line-of-business applications because of their standardization and coverage of nonfunctional aspects.

¹⁶ REST abbreviates Representational State Transfer and is a more lightweight counterproposal to WS-*. It relies on the capabilities of http/https and intends to offer a simple-to-use, wide-ranging communication API to Web applications.

¹⁷ The acronyms WOA and MOA abbreviate Web-Oriented Architecture and Message-Oriented Architecture, respectively.

¹⁸ CORBA stands for Common Object Request Broker Architecture and is the most elaborate platform- and programming language-independent standard for distributed objects.

¹⁹ In Indian mythology, Draupadi is the guardian deity of noble education and supreme knowledge. She was born all-knowing and possessed 32 auspicious qualities (rujus) at her birth. Draupadi symbolizes the knowledge accrued when noble deeds are performed with an attitude of surrendering everything to God (Lord Krishna in Hindu philosophy).

²⁰ Marcus Vitruvius Pollio was a Roman writer, architect, and engineer who was active in the first century BC. He is best known as the author of the multivolume work De Architectura (On Architecture).

²¹ Industry standards are widely accepted by software vendors, implementers, and systems integrators. Their specifications are in some cases controlled by neutral forums such as W3C (Worldwide Web Consortium), OASIS (Organization for the Advancement of Structured Information Standards), or OMG (Object Management Group). There also are de facto standards not controlled by any such forum but still so stable that they are generally accepted. Examples are JEE; .Net technologies; the JBoss Application Server; Java frameworks like Seam, Struts, or Hibernate; or Adobe’s Portable Document Format (PDF).

²² This is a complied, condensed version of concrete examples of EA mandates we have come across in various projects and in many companies.

²³ Steve Yegge posted an internal memo on Google+, which by mistake was leaked into the public domain. The narration quoted here is from this memo posting, known as Stevey’s Google Platforms Rant.

²⁴ Initiatives are expressed as intentions and work streams. They are coarsely defined at a high level with work packages and ballpark estimates. In contrast, projects are more concrete. They are defined in a formal way using a statement of work, a project charter, or a project proposal.

²⁵ LOB stands for line of business.

²⁶ We can recommend the book IT Portfolio Management Step-by-Step: Unlocking the Business Value of Technology, by Bryan Maizlish and Robert Handler (2005), or the MIT Center for Information Systems Research Website at http://cisr.mit.edu/research/research-overview/classic-topics/it-portfolio-management/.

²⁷ Integration complexity may be expressed as a function: Integration Complexity = f (i1, i2, i3), where i1 = relation complexity (how many systems or instances a system has a relationship with), i2 = interface complexity (how many different business objects the system integrates for), and i3 = integration complexity (how many different mechanisms/techniques/methods are used to implement the integrations).

²⁸ Bill Bryson, I’m a Stranger Here Myself (1999, p. 168).

²⁹ See Larman and Vodde (2009, p. 285).

³⁰ ISACA is an independent, nonprofit, global association engaging in IT governance practices and standards. The group’s bestseller is the IT governance standard COBIT (Control Objectives for Information and Related Technology). It is complemented by Value IT and Risk IT, frameworks for investment and risk management.

³¹ New York Mercantile Exchange, the largest trading place for raw material and commodities.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for Chapter 3. What Enterprise Architects Do: Core Activities of EA

Create new playlist

Sign In

Sign Up

Chapter 3

What Enterprise Architects DoCore Activities of EA

Content