The Strategy blog

Oscar Salgado, the chief architect of our Bank4Us EA case, has recently participated in the maxim workshop spelling out the CIO’s Closer to Customer mission statement set out in Chapter 3, activity EA-1, Defining the IT strategy. The outcome has now been published as a slideshow to the employee portal. But Oscar knows his IT crowd inside out: They will play a round of buzzword bingo¹² with it and turn to something “more substantial.”

During the workshop, Oscar learned a lot about the business concerns, the market conditions, and the financial figures that are causing a headache for higher management. He understood that customer empowerment, one of the strategic goals of Bank4Us, is more than a marketing label. Many of the services still offered at the bank’s branch offices are too expensive and simply must be replaced with Internet-based self-services. This is not a matter of value-adds but of financial survival.

Oscar has also started to believe that the initiatives subsumed under customer empowerment can really make a difference to the consumer. The idea of a financial dashboard, for instance, that transparently shows the customer’s financial health state at any time and on any device—desktop, smartphone, or tablet—is something Oscar would actually like to have for himself. One workshop participant brought this example up, but such details didn’t make it to the strategy slides.

After some hesitation, Oscar decides to publish his insights regarding the strategy in some blog posts. He feels a bit uneasy about it because it is a different kind of writing than the impersonal, matter-of-fact stuff he usually authors. On the other side, he is a seasoned consultant and knows that showing some passion about the strategic goals helps win over the people in the company. Therefore, he decides to make himself a spokesman of the strategy and utter some personal views at the risk that technocratic mockers among the IT crowd might enjoy tearing them apart. But he is convinced that a deeper understanding of the strategy’s motivation, a clearer view of what it means in practice and a closer identification with the goals, will help kick off the mission. Dave Callaghan, his boss and CIO, embraces the idea and encourages Oscar to do so.

The EA group has long played with the idea of utilizing a social software platform (SSP) for the sake of architecture management. Leon Campista, a peer of Padma Valluri on the EA team focusing on processes and methods, is acting as an evangelist for Enterprise 2.0 and has set up an SSP on the corporate intranet to invite participation. Hence Oscar decides to volunteer as a trailblazer and posts his first blog to Leon’s SSP, as shown in Figure 8-7.

Oscar’s blog post addresses the economic reasons behind customer empowerment, the opportunities it offers, and the implications for the technical landscape. Nevertheless, the major part is less concrete and analytical; it is about finding the right slogans, scenarios, metaphors, and comparisons. Two Japanese founders of modern knowledge management, Ikujiro Nonaka and Hirotaka Takeuchi, would applaud this approach. Their classic The Knowledge Creating Company (1995) furnishes evidence of the importance of nonanalytical knowledge in giving organizations a common direction.

Oscar, for instance, compares messages that Bank4Us currently provides to its customers about their savings with the information parents receive from their teenage kids on a school trip to Paris. Every now and then, you get some difficult-to-decipher messages on how they’re doing, but all in all your insight and influence are rather limited. This resembles Oscar’s impression when he receives monthly account statements about his equity fund.

After publishing his post, Oscar remembers Leon’s advice that Enterprise 2.0 platforms must be valued (as explained in “A Primer on Enterprise 2.0”), and he asks some peers to read his blog. They in fact take up the blog as a means of spreading the word and add comments contributing their own notes and points of view.

All in all, the majority of the IT crowd welcomes the blog posts because they add some beef to the meager maxims of the strategy slides. Leon, acting as the technician behind the SSP, has added a widget to the blog whereby readers can assess the usefulness of the document. The enterprise architecture group wants to use this as a criterion for a regular clean sweep of the SSP to avoid the proverbial document graveyard.

Yet blogs are still rather unidirectional and similar to the bulletin-like publications found in most employee portals. Blogs elicit comments but do not invite participation in the full sense. There is another example at Bank4Us that goes one step further: the ObjectPedia.

Collaborative data modeling: The objectPedia

Data modeling always has been a headache at Bank4Us. Until a few years ago, the company did not have an explicit, enterprise-wide data model. Some units had a detailed, rigid model—in particular those dealing with accounts and money transfers—but others, such as marketing and sales, were drowned in an unconsidered proliferation of concepts and database entities. However, with the advent of more and more cross-unit business processes and the struggle for a unified, seamless customer interface, the absence of an enterprise data model grew into an obstruction. This problem became particularly visible with the introduction of an enterprise service bus (ESB) as a data exchange platform.

Steve Pread, the enterprise architect in charge of the data architecture, has sent a cry for help to Padma Valluri, who maintains the EA processes at Bank4Us. The process for bringing business objects (BOs) into the ESB draws heavy criticism. To ensure the interoperability of services, Steve’s team had been entitled to be the only authorities defining BOs that are admissible as service parameters in the ESB.

The objective was a unified data model shared among all service providers and consumers in the ESB. But that turned out to be overambitious. Steve’s team was soon overloaded with requests from projects. Furthermore, his architects did not understand the semantics of the hundreds of BOs well enough. Finally, they also had to acknowledge that the dozen interpretations of a central BO like “customer” all had good reasons: The marketing view of a customer is essentially different from what bank transactions attribute to this entity. Hence, Steve asks Padma for a pitiless inspection of his approach.

Padma, seeing this as an opportunity to show the benefits of the recently developed lean toolkit, invites Steve to a process activity mapping of the BO definition, review, and approval process (see Building Block 1 in Chapter 7). They soon agree that more autonomy must be given to projects and that central control of data definition must be given up in favor of a federated, self-organizing approach.

After some days of self-critical musing, Steve comes up with the idea of an ObjectPedia, a social software data dictionary along the same lines as Wikipedia. Padma immediately embraces this suggestion because it points to the direction of the just-in-time modeling and iterative design she regards as a prerequisite for the EA Kanban idea (see Building Block 3). Together Steve and Padma draft a first sketch of this platform, as shown in Figure 8-8.

The page has some standard SSP functions that Padma and Steve find promising:

But a Website is just a start and is not sufficient for self-organization. Leon Campista, the EA 2.0 evangelist, reminds Padma and Steve of the advice that Enterprise 2.0 platforms must be governed by carefully defined rules and norms (see “A Primer on Enterprise 2.0”), and together they constitute the following ObjectPedia Charter:

The charter also lists some rules governing the integration with the overall software development process:

The charter gives wide autonomy to the projects and downsizes the role of Steve’s team to consultancy and moderation. ObjectPedia will have a version and change history as well as discussion pages, like Wikipedia. But with these facilities, projects are left to their own responsibility for resolving conflicts. They can approach Steve’s modeling gurus for advice but shouldn’t expect that they’ll get an authoritative model from the top down.

Padma, Steve, and Leon are convinced that this scheme might work. They present the idea to Oscar, the chief enterprise architect, on the next possible occasion and win him over to fight for a prototyping budget. But they also know that efforts go beyond planned SSP implementation: Weakening the grip in favor of self-organization is a brave step and needs some coaching during ramp-up. It is a long haul, as Andrew McAfee puts it (2009).

The Bank4Us example is a case where the designing capabilities of a central authority did not suffice to tame the complexity of an enterprise data model. Way back in our Reflections on Complexity, we gave some reasons that a network of autonomous designers has the potential to do better: It gets more hands on board and benefits from a diversity of knowledge. ObjectPedia shows how this can be achieved in an EA context.

Weak ties and a self-organizing application landscape

Ian Miller, the Bank4Us enterprise architect whom we already encountered on several occasions, has recently drafted a landscape map of the Internet portal applications in the online banking and trading business domains. An excerpt of this map is shown in Figure 8-9. The map is a view of the as-is architecture and addresses several stakeholders: developers, operational staff, and planners.

It was a strenuous effort to draw the full map consisting of 46 applications and 129 application interfaces. But Ian is an old hand and knows the fate of such architecture views: They are inaccurate from the first day onward, and their reliability melts like ice in summer with each release of an application. Developers and operational staff start ignoring the map as soon as they discover major inaccuracies, and planners will blame Ian if they base erroneous decisions on faults in the map. It has happened more than once that the credibility and reputation of the enterprise architecture group was damaged by such blaming that eventually escalated to the CIO.

The enterprise architecture group had pursued various approaches to ensure the accuracy and timeliness of models. They mandated that development projects had to submit their architecture input at defined milestones, and they monitored the projects by architecture compliance reviews as described in Chapter 3, “Monitoring the project portfolio (EA-6).”

But the results of these governance mechanisms were disappointing for various reasons: The projects unwillingly submitted just a minimum of information “to make the EAs happy,” or the project architect did not have sufficient insight into the de facto implementation, or the delivered input was already outdated when the release went into production. In many cases, models were simply abandoned or kept alive at high cost by frequent and laborious software archeology. The run for up-to-date models felt like an inverse “hare and hedgehog” race: Whenever the modeler was under the happy impression he had captured reality, the de facto implementation had already moved on to a different place.

To escape this dilemma, and with growing support for ObjectPedia in the offing, Ian decides to publish the landscape map to the SSP and open it for comments, corrections, amendments, and evaluations by the IT crowd. A realization of this idea is sketched in Figure 8-10.

The site has some standard functions of an SSP: tag clouds to facilitate searching, feeds to raise the awareness of changes, and usefulness ratings to alleviate cleansing. But the treasure is in the content-related comments that Ian harvests in a corresponding subpage (see Figure 8-11).

The inaccuracy pointed out by software engineer Harriet and the service-level concern discovered by system operator Carl are exactly the fallacies that would probably have not been discovered without the SSP. Ian knew Carl, and maybe he would have stated his concern in an ordinary review of the architecture specification. But Ian had no relation to Harriet; she was one of the so-called potential ties connected by the SSP.

So far, so good—but this site has shortcomings:

Hence, Ian would like to take one step further in the direction of a self-organizing application catalogue. The project teams are currently submitting their input to the ACR on Excel sheets. They could as well use an SSP site like the one shown in Figure 8-12.

The site provides a template in which project architects can fill in the details about their applications. The landscape map is then generated from this input without further manual work.

Meanwhile, Ian starts appreciating emergent models and wonders whether self-organization could not also answer a notorious meta-problem involved in templates, as shown in Figure 8-12. Templates like this one incorporate the taxonomy of enterprise architecture—for example, the EA understanding of the concept “application.” But the application domains are different and the technologies widespread, so a template that makes sense to all is a least common denominator conveying just meager information.

Ian started his career as a software developer in the data warehouse (DW) domain, and he implemented ETL¹³ flows by means of Perl and Structured Query Language (SQL). At that time, Common Object Request Broker Architecture (CORBA) was the ruling hype technology, and all architecture documentation standards at Bank4Us were targeted at CORBA applications. The templates were all about components, implementation-independent interfaces, IDLs,¹⁴ stubs, skeletons, and interface operations. Ian remembers how awkward it was to express his file- and database-centric mass data flows in these terms. It also felt as though his well-thought-out, useful flows were something dirty or half-legal.

From reviewing the input the project teams submit to the ACR, Ian got the impression that many project architects are scratching their heads as they fill in the templates. They do not feel at home in the taxonomy designed by the EA team. What if this taxonomy could also be emergent and he could invite the project architects to shape it according to their views on the subject?

Recent research conducted at the Technical University of Munich gives an idea what such an emergent taxonomy could look like (Buckle et al., 2010).¹⁵ The research group Software Engineering for Business Information Systems (SEBIS) promotes hybrid wikis as a tool for emergent meta-models. Hybrid wikis are not completely structureless like the ordinary tabula rasa wikis, but they also are not rigidly prestructured by templates, as in the case of Ian’s application catalogue site. Their structure is given to self-organization, and the taxonomy emerges while users are editing contents. The method of choice to achieve this functionality are typed tags. These tags are not simply strings, as in the case of ordinary tags, but key-value pairs. An example is shown in Figure 8-13.

The application FinS is tagged with several typed tags—for example, with CatalogueItem and JavaEE. Therefore, FinS inherits the simple attributes ID and Name from CatalogueItem and the multivalued attribute Libraries from JavaEE. As usual with tags, users can create their own typed tags while editing contents in the HybridWiki. An author in charge of some ETL flow would not pick the JavaEE tag but could annotate the flow with a new typed tag. This tag would be specific to ETL flows and list the target database tables and shared stored procedures being accessed. After creation, it would be available to other authors, too.

The SEBIS research group distributes an open source hybrid wiki called Tricia. The video recording at (SEBIS, 2012) nicely demonstrates how a meta-model emerges on the fly while users are editing contents with this SSP. The researchers also discovered EA as an application domain for hybrid wikis and founded the industry collaboration Wiki4EAM to proceed in this direction. It will be interesting to follow their work.

Summing it up: Assessment by the EA Dashboard

Throughout this section we’ve come across blueprint examples of how Bank4Us embarks on Building Block 4, Participation in knowledge. The tools range from straightforward ones, like Oscar Salgado’s Strategy blog, to rather futuristic means, like Ian Miller’s vision of a hybrid wiki application catalogue.

The addressees of the given examples are the IT crowd, but knowledge sharing is certainly not confined to this target group. Ian’s application landscape, for example, can easily be extended by forum elements to a collaboratively written user manual that invites users to share their best practices and tricks. We don’t have to dwell on this; today half of the user knowledge about publicly available software is not in the authoritative manuals but instead written by the users themselves.

The examples support various EA activities (often even more than one) and apply several techniques of social software platforms (SSPs); Table 8-1¹⁶ summarizes these.

Table 8-1 Building Block 4: Supported Activities and Employed Techniques

In this table, a solid bullet marks the most crucial techniques, whereas a hollow bullet denotes a feature that plays a role but is not key. Nevertheless, the general, ubiquitous functions of an SSP should not be underestimated. The ability to connect people and make the network participants aware of what others are thinking and doing is presumably a paramount benefit of an SSP. Only the landscape map explicitly highlighted this benefit, but it is implicit in the other examples, too.

What more specific benefits can we expect for EA? Figure 8-14 measures the expected value of Building Block 4 on our EA Dashboard.

Since Building Block 4 is about knowledge but not about taking action, the expected impact is on the order-chaos dichotomy but not on the timeline.

Tools like ObjectPedia and the landscape map are dedicated to guiding EA out of “Cloud Cuckoo Land.” Their very essence is to meet implementation realities and local knowledge on the ground. The Strategy blog, on the other hand, demonstrates that EA 2.0 tools can also help propagate business concerns and visions among the IT crowd. The Perspective gauge therefore deserves arrows in both directions but with a stronger emphasis on getting our feet back on the ground.

ObjectPedia was initially designed to overcome a governance bottleneck: the solitary top-down definition of a data model by EA. The application catalogue and its futuristic twin, the hybrid wiki, exemplify how the mode of documentation obligations can change from top-down examinations to a more self-responsible authorship of projects. Hence, we expect that Building Block 4 can help the guardians of wisdom weaken the grip.

The diagnostic process landscape

Bank4Us in the meantime has taken further steps toward Enterprise 2.0. The social software platform (SSP) launched by the EA group is now applied beyond the bounds of the IT crowd, too. The extensive office manuals giving instructions on how to perform activity X of process Y have been accompanied by a forum, as shown in Figure 8-15.

The forum is gathering best practices from daily work; it is a self-written user manual. The user contributions arrange themselves around the process landscape model of EA, which works as a crystallization point for this knowledge. All users directly or indirectly involved in a process can post advice. The motives for authoring are widespread: Some authors just want to help other poor strugglers, some recognize the SSP as a valuable source of information and want to pass knowledge back in return, whereas others enjoy being regarded as old hands and advisors in their specific areas.

Furthermore, it feels good that the SSP to some extent makes the practitioners owners of the process. This in particular holds true for the rating widget, which is also the interesting part with regard to choosing future directions and making decisions. It collects the pain points from those who feel the pain.

Franca Bertapelle, for example, a local advisor at the branch office in Pittsburgh, rates the business case evaluation process step (a customer applies for a loan, and Franca needs to qualify his case) quite low. She complains that she has to apply several heuristics to assess the profitability of a credit application, but there are no means to transfer data from one heuristics to the next, which implies that she has to type the same data again.

The idea for this rating and the “Have your say” box did not come from the EA group but from the users. Nevertheless, it has become an important diagnostic tool in activity EA-3, “Evolving the IT landscape.” In assessing the sanity of processes or applications, the EA group still collects input from experts, but they never draw conclusions without taking a look at what the users report. If the user ratings suggest that a process is cumbersome and poorly supported by IT, an expert’s praise for it will be taken with a grain of salt.

The diagnostic process landscape is a straightforward quick win with Enterprise 2.0. The next example, however, is more subtle and not only prepares decisions by gathering information but drives them to a result.

The bazaar of IT opportunities

Given the right circumstances, crowds are not only good at assessing present things but also at prognosticating the future. One of the most famous research projects in this direction is the Iowa Electronic Market (IEM) project conducted by the Henry B. Tippie College of Business at Iowa University (Surowiecki, 2005, p. 40). The project started in 1988 but is still under way. IEM is an online, not-for-profit trading market where traders can trade prospects with real (but relatively small amounts) of money.¹⁷ Prospects are statements about a future course of issues—for example:

Traders can buy, for example, shares of P1, and if the German chancellor in fact wins the elections one year later, they receive US$1 as revenue per share. The price of the shares depends on the market supply and demand: If the price of a P1 share is 52 cents, IEM prognosticates a 52% probability that the current chancellor will win. The second prospect, P2, is more fine-grained: The revenue depends on the percentage of votes the Democrats win. Assume they attain 56%; then the owner of a P2 share receives 56 cents in return. A price of 48 cents per share is therefore interpreted as a prognosis that the Democrats will win 48% of the votes.

The IEM frequently outperforms the survey-based prognosis of accredited statistical institutes—presumably because the traders pay more attention to it than to a nonbinding survey and the market mechanism has more self-correction capabilities than the plain summation of polled opinions.

Two items that frequently need to be prognosticated in IT are effort and business value of a solution alternative. Effort estimation finds support in a rich toolbox of techniques,¹⁸ but business value estimation is still in its infancy. Big strategic IT initiatives usually undergo a business case assessment that somehow numbers their expected value. But for so-called IT opportunities, such an approach causes too much effort or is principally impossible due to a lack of predictability.

The term IT opportunity (ITO) was coined by Broadbent and Kitzis (2005) and denotes the bag of ideas and bleeding-edge innovations complementing the big strategic initiatives. IT opportunities are typically perilous, in regard to the expected outcome or technology. They are the wildest among the Wild Cats in the Ward-Peppard square (see the section “Assessing Applications”).

Broadbent and Kitzis recommend designing a management process for the highly volatile bag of ITOs in parallel with strategic planning. The process should be shaped like a funnel with a broad entry for gathering the rich plenty of ideas but an early and rigid cutting down to the really smart ones. What would be more suitable than a marketplace for implementing this funnel? Folks can easily place an offer, but if it doesn’t sell, it’s out.

Padma Valluri, the enterprise architect at Bank4Us who focuses on EA processes, finds marketplaces like IEM highly inspiring. Together with Leon Campista, the Enterprise 2.0 evangelist, she proposes the idea of an ITO bazaar and eventually convinces the EA group and management to furnish it in the EA social software platform (SSP). The prototype Leon helped her set up is shown in Figure 8-16.

The site again shows many basic functions of an SSP: tags, RSS feeds, links to people and further assets, and the possibility of leaving suggestions. But its most remarkable feature is the bidding widget on the right side. There people can bet how much effort is involved in the realization of the ITO and, as an option, can also offer a certain amount of person days they are willing to contribute to the solution.

Betting on the effort is just a game. People who came close to the de facto effort (determined after the implementation) are rewarded with a corresponding number of scores that can be converted into money in an online store.

Offering a certain amount of work time, however, is more serious. Bidders are responsible for ensuring that, if the ITO indeed becomes a project, they can fulfill their offering. Project managers like Sarah Mathews should ensure that her team has the needed capacity, and individual software developers like Jake Bertapelle should agree with their supervisors to be exempt from other duties to the extent needed.

There is no automation behind the ITO bazaar that kicks off projects. If an ITO gains sufficient interest—meaning that the ratio of available offerings and estimated effort exceeds 100%—bidders are invited to a meeting with the project portfolio management. This is to check that the preconditions for a kickoff are given and in particular that all bidders can fulfill their shares.

This bidding mechanism helps estimate the true business value of an ITO: Only if there is a need for the proposed solution, and sufficient faith in the success of the idea, does the ITO get funded. Furthermore, the mechanism mitigates a chicken-race problem related to the funding of shared, cross-unit software components: In the past, the first unit to jump on such a component had to pay the price all alone.

There was a saying in Bank4Us that “The first guy who wants to swim has to pay for the swimming pool,” which is a break for both innovation and cross-unit collaboration. The bidding mechanism puts an end to this idea by bargaining a fair sharing of the efforts.

The ITO bazaar is open to the IT crowd but also to others with sparkling ideas about the profitable exploitation of information technology. The filings therefore range from rather down-to-earth, technology-driven submissions like the one shown in Figure 8-8 to high-flying exciters. But this variety is put under EA governance: Each ITO needs approval from the EA group before it is open for trading. The reasons for erecting such a quality gate are:

Whether such a quality gate should be erected was the subject of fierce discussion at Bank4Us. Some opponents believed it endangers the free development of the market (the discussions showed the usual traits of debates about market regulation). The convincing argument in favor of such a gate was a look at the governance of open source software programs: They also employ quality sieves to prevent the essence of the program from being eroded by nonfitting projects or the grooming of hobbyhorses.¹⁹

Experience will show whether the previous “business model” for the ITO bazaar will work out. This model is the essence of the ITO bazaar, and its functionality needs more attention and care than mere tooling. The responsible parties at Bank4Us therefore decided to set up frequent monitoring and optimization of the trading rules.

Summing it up: Assessment by the EA Dashboard

Building Block 5, Participation in decisions, applies the principles and techniques of Enterprise 2.0 to choosing future directions and making decisions in connection with EA. We have seen two examples from Bank4Us of how this looks in practice:

The EA activities and SSP techniques of these examples are summarized in Table 8-2.²⁰

Table 8-2 Building Block 5: Supported Activities and Employed Techniques

In summary, what do we expect from Building Block 5 for EA? Figure 8-17 measures the expected impact by the EA Dashboard.

The essence of participating in decisions is giving a voice to the crowd with respect to identifying where there is need for action and exploring alternatives. We can therefore expect it to set the perspective right if this has lost contact with the ground-level realities (Cloud Cuckoo Land). Furthermore, the building block is an antidote against a tunnel view in strategy, a single faraway vision that is mostly based on the beliefs and wishes of the top brass. The reality check ventilated by the SSP may draw EA away from its hypnotic fixation on the crystal ball and uncover additional tracks worth following. Furthermore, participating in decisions establishes a funnel for ideas and innovations, as the ITO bazaar demonstrates. It therefore can help us escape from congealing that anxiously focuses on keeping the existing system running; hence, the transformation gauge is rising, too.

Mashing up the architecture continuum

Enterprise architectures are not monoliths, they are mosaics composed of architectures designed by different owners. In Chapter 7 we came across a classification of architecture types by granularity into strategic, segment, and capability architectures. The architectures of this classification are nested according to the dimensions of time horizon, subject matter, and level of detail. They range from long-term, far-reaching, and high-level strategic architectures to short-term, special, and detailed capability architectures. Furthermore, these architectures are usually crafted by different teams of architects.

Beneath the capability architectures, we even find another layer of architectures made up of the daily design decisions of development teams and therefore yet another team contributing to the overall picture. This daily hands-on layer is not irrelevant. During the 2010 conference of The Open Group in Amsterdam, Len Fehskens, vice president of this organization, asked where the borderline between architectural Design (with a capital D) and design (with a small d) actually is. This line is indeed difficult to draw when adopting a definition of Design such as Booch’s explanation of architecture, “[…] the significant design decisions that shape a system, where significant is measured by cost of change” (Booch, 2006). On this ground, the borderline presumably meanders across the teams, as shown in Figure 8-18

The assumption that design decisions on a lower layer can be revised at low cost turns out to be wrong in practice: The innocent decision for a certain primary key in some database table design can freeze change in some wider application domain for years.²¹

Another rationale for continuity is reuse. The Open Group has conceptualized the vision of what they call the architecture continuum. It is a subdivision of the enterprise architecture according to generality. Figure 8-19²² depicts the four divisional classes.

The flow from left to right goes from general to special, from technology focused to business focused, and from logical to physical.

The more specific architectures on the right reuse the more generic ones on the left. They use the capabilities of general building blocks—for instance, the functionality of a general single sign-on security solution, or are embedded in a more general frame, for instance as concrete SOA service providers in the service landscape of BIAN.

The two architecture classifications—by generality and granularity—are different but not entirely orthogonal: The foundational architectures typically belong to the strategic class, just to name one correlation. Nevertheless, there are strategic elements in the organization-specific architectures as well as quite detailed capability architectures among the common system architectures, so the two classifications are founded on widely independent dimensions.

Common to both classifications is a rich network of links that exist between the different architectures—and this eventually is where Web 2.0 comes into play. The design principle of remixability and the focus on linking and backtracking content provide the ideal ground for mashing up a true architecture continuum. Web 2.0 renders possible an architecture knowledge repository that is consistently navigable across multiple dimensions, integrates data and models from various sources, and facilitates a continuous flow from high-level strategic plans to code design or from standards to custom solutions.

Padma Valluri, the lean evangelist among the enterprise architects, is excited by this vision set forth by her EA 2.0 counterpart, Leon Campista. She is convinced that a continuous flow of architecture design across strategic, segment, and capability teams down to code design (with a small d) cannot be achieved with plain old paper documentation. But this flow is at the heart of the EA Kanban and is a prerequisite for a continuous integration of designs. Padma therefore supports Leon’s struggle for some time and budget that would allow Leon and his helping hands to prototype the idea sketched in Figures 8-20 and 8-21.

The prototype’s first page shows a map of the application landscape mashed up with information stemming from various sources. The map serves as a navigational component—a mouse click on an application rectangle, an interface bubble, or a dependency arrow brings up related information in the other widgets of the page. The information these widgets display depends on the selected item and whether it is an application, an interface, or a dependency. For an application, the linked-in information is about system management, operating environments, the BIAN service area the application is mapped to, and other items worth knowing. An interface, on the other hand, is displayed with a different set of items.

The links highlighted in Figure 8-20 are pointers to more generic architectures. They either point to entire pages—the System Management link to the Tivoli Monitoring common system architecture is such a case—or to data items provided by the higher-level architectures, as in the case of the BIAN combo box that displays the service areas available in this industry-specific architecture.

While these navigation links are paths from specific to more general architectures, a different kind of magic happens when we double-click on the FinS application rectangle: The SSP drills into a deeper level of detail. Figure 8-21 shows the target page, the decomposition of FinS into subsystems, which is the highest application-internal part of Kruchten’s Logical View²⁵ on the software architecture.

The logical view is mashed up with links to more generic architecture building blocks—for instance, with a link to a common database caching architecture. Double-clicking on the subsystem rectangle, on the other hand, zooms deeper into the inner structure, eventually down to class diagrams, scenarios, pages with HTML-formatted code headers, and so on.

In addition, there are links into requirements management and quality assurance. They direct the user to requirements and test cases pertinent to the subsystem that is currently in focus. These navigation paths connect the architecture SSP with other knowledge islands of a transformation program.

Leon’s plans also include microblogging as a means to capture the daily design decisions and changes. The postings are grouped by software subsystem. Here is an example: While pair programming, Sachindra Lele and Anne Calten (two developers) decide to switch database access from an optimistic to a pessimistic transactional locking and report this decision to the microblog.

This can be a useful piece of information some days later if a sudden database deadlock or lock timeout problem occurs in the next round of load testing. Multiple channels are open to this micro-blog: the SCM²⁶-system, a standalone desktop or Web user interface, an SMS, a mobile app, or whatever else is used in daily work.

The benefits that Leon and Padma list to promote the architecture continuum mashup (ACM) idea are:

Leon’s microblog is a ground-level example illustrating the last bullet quite well. The next section’s Bank4Us case, however, comes up with an even more thrilling story of how Enterprise 2.0 can bridge gaps between knowledge islands.

The change management microblog

Knowledge islands can be fatal. One of the most well-known examples is the failure of the US intelligence community to spot the 9/11 attacks in advance. “In the months preceding 9/11 troubling signs were apparent to intelligence agents and analysts throughout the world,” writes McAfee (2006b, p. 31). But there were 16 agencies making up the US intelligence community, and they shared information reluctantly (if at all) and ineffectively. Furthermore, the prevalent safety culture in these agencies was “need-to-know”—do not let people know more than what they absolutely need to do their duties. Hence, all the knowledge was there, but no one was able to piece the jigsaw together.

In 2011, 10 years after 9/11, a similar case was discovered in Germany. A small group of extremists had committed acts of terror and murdered a still undetermined number of people over a period of 10 years. In retrospect, the units of the highly federated law enforcement agencies had all bits of information they needed to arrest the group years previously, but the bits were “safely” isolated and locked away.

Enterprises are not doing better than governmental agencies in this respect: They also fall victim to knowledge islands. The consequences may not be as deathly—in particular, when thinking of the comparably harmless failures in IT—but they nevertheless do harm. When a consultant is helping companies in matters of IT problems, the value the consultant adds often is not in the additional knowledge she brings but in the fact that she listens to stakeholders from all parties. It sometimes is stunning: All the knowledge is already there, but it needs an external player to put the puzzle together.

Likewise, when tracking an IT failure back to its root causes, one often discovers that the problem could have been avoided if only two or three people had shared their knowledge. A test engineer, under full steam to get a release out the door, manually changes the JVM heap size²⁷ of an application server to get rid of out-of-memory exceptions and kick off functional integration testing.

One week later, the same lack of memory rocks the boat when the tested release is being deployed in production, this time with a customer-facing outage that is brought to the attention of the CIO. The information about the change simply got lost in the chain from test engineer over project manager to release coordinator and eventually to the administrator of the production server.

The causal chain often is much more intricate than in the previous example. Sarah Taylor, program manager at Bank4Us, feels like yelling at someone. One of the critical applications she is accountable for suddenly crashes without apparent reason during the early morning hours and even brings the whole server down. Restarting the server helps, but the outage inevitably happens again the next morning. The affair is a red flag to senior management boards, and Sarah has to defend herself each morning in a telephone conference with Dave Callaghan, the CIO. Her team is working overtime on troubleshooting but feels a bit lost, in particular because the failure cannot be reproduced in the quality assurance environments.

During an ad hoc brainstorming session with administrators, they learn that the number of CPUs of a client system had been doubled, which caused a higher number of requests to the critical application. But the upgrade happened one week before the first outage, and the system supervision logs prove that Sarah’s application handled the change smoothly, according to the service-level agreements. What else could it be?

An operator tells Sarah that he had shifted the file backup of the critical application to morning hours. This time coincidence is suspicious, yet the shift is a proven, ordinary procedure, and it was applied three days prior to the first disaster. The days pass and the outages constantly recur each morning. Dave is getting more and more impatient when finally the crucial bit of information is revealed in a cross-departmental emergency meeting: The backend system Sarah’s application is relying on for calculating interest rates had reverted to an older set of business rules just one day before the nuisance started.

Financial analysts had discovered that the new calculation rules for one of the financial products were disadvantageous. But the older set of rules, though long proven under earlier circumstances, had some more complicated calculation algorithms, and that was the last straw. With the increased volume of requests, the resource consumption of the file backup, and the slightly longer response times from the rate calculation, threats were queuing in Sarah’s application and eventually choked the whole application server.

IT “thrillers” like Sarah’s hot-headed days of haunting outages happen all the time. In the end there also is no one to arrest, since all actors did perfectly reasonable, admissible things. The mutual impact of well-thought changes to the IT landscape accumulates to a failure for which no one is to blame.

This is one of the traits of a complex system that we highlighted in “Reflections on Complexity”: The addition of linear changes such as the increase of requests or the longer response times of rate calculations suddenly pile up to an exponential growth of threats destabilizing the whole system. In addition, the failure pops up at a spot that’s at first sight rather unrelated to the changes: It hits the innocent stranger, so to speak. Figure 8-22 shows the pattern.

There are failures that happen simply because somebody did something wrong, but the pattern shown in Figure 8-22 is usually more difficult to hunt down. It also poses the more severe organizational challenge: Preventing wrong acts is one thing, but coordinating best practices of several actors so that they do not collide is a more intricate matter. How can we avoid incidents like the one we’ve described? Furthermore, presuming that we never will be able to completely ban them, how can we at least shorten troubleshooting times? In Sarah’s case, it took more than a week before the team eventually understood what was going on.

One countermeasure is to rely on tools like change and incident management applications or a configuration management database (CMDB). This is perfectly valid, even recommendable, but a closer inspection of the two cases shows that it is not a panacea. These tools are confined to a narrow group of users such as administrators, release coordinators, or operational staff. The test engineer has no access to these tools for reporting the JVM parameter change, and the business analyst does not even know what a CMDB is, not to speak of logging changes to calculation formulae with it.

Another countermeasure is to fine-tune processes and information flows. This again is reasonable, even a mandate. But constructing a channel of information obligations in a way such that those who need to know will know is like solving the traveling salesman problem: The effort grows exponentially with the number of people who need to know.

Figure 8-22 shows that activities and effects cross the boundaries of organizational units. The financial analyst who reverted back to the older calculation formulas, the administrator who upgraded the client system with new CPUs, and Sarah belong to different communities of practice. In 99% of their activities, it is all right that they are not aware of what the others are doing; their respective knowledge islands provide sufficient information. However, there might be this 1% residuum that no one can guess in advance.

But this is where Enterprise 2.0 can come to the rescue—not as a replacement for the traditional countermeasures explained previously but as a complement. The general accessibility, the enhanced search capabilities, and the ease of use of Web 2.0 can help to bridge the gaps between the knowledge islands and convert potential ties into actual ones as needed.

What if all people who performed changes to the IT landscape would send notice of their activities to a microblog? After pausing for a breath, Sarah decides to do something about the ineffective troubleshooting she experienced. She schedules a meeting with all involved colleagues for a retrospective analysis. Ian Miller, the enterprise architect looking after Sarah’s applications, attends as a matter of course and brings Leon Campista with him. Leon has circulated the idea of using microblogging as a means to manage changes of the IT landscape. What he impassionedly explains to Sarah and the other listeners is sketched in Figure 8-23.²⁸

The starting point of Leon’s idea is that all IT transformers notify their activities to a microblog. This group of transformers includes administrators, operators, installation engineers, release coordinators, testers, project managers, software developers, and content editors (like the financial analyst in our example)—basically all actors who directly change the IT landscape.

The number of actors will be roughly 800 in the case of Bank4Us. Leon estimates that if blog posts are kept at a reasonable level of interest, the average number would be one or two blog posts per actor per day. Administrators presumably post their hands-on screwing and installations more often, maybe on an hourly basis, whereas project managers or software developers would stick to more infrequent summaries of their day-to-day activities.

Nevertheless, the numbers indicate that some intelligent filtering must be applied to the stream of blog posts to give those who are seeking help a chance to discover the relevant bits. The filtering that does the job in public microblogs like Twitter is based on personal relations: You receive posts only from those you want to follow—your friends, relatives, colleagues, role models, or whomever you are interested in. But this is insufficient, even counterproductive, in the case of a change management microblog: The essence of the idea is to transcend awareness beyond the boundaries of those you are following anyway. There’s a wide range of filter criteria, including:

The last bullet deserves a broader explanation: The IT Infrastructure Library (ITIL) is a de facto standard for planning, building, and running IT services. It evolved out of the operational side of IT but has expanded to a full-fledged framework of good practices for providing IT services to an organization. One of its assets is a catalogue of change processes and activities at the operational level (Cabinet Office, 2007), and this is what the last bullet is referring to.

Leon has no time to prototype the idea of a change management microblog. Nevertheless, he presents the simple draft shown in Figure 8-24 to Sarah, Ian, and the other brainstorm attendants to sketch the idea.

Small stickers position the activities on an application landscape; their color code marks how recent the activity is. The search widget on the right-hand side supports several filter criteria, in particular the ITIL activity categories. Table 8-3 displays the search result, and as the example indicates, users with quite different roles logged their doings there: Ralph, an administrator; Saptarshi, a software developer; and Scott, an associate from marketing who is responsible for placing advertisements on the company portals.

Table 8-3 Building Block 6: Supported Activities and Employed Techniques

Leon’s audience immediately comes up with a wish list of enhancements and changes to this sketch. Nevertheless, they strongly agree that a tool like this provides the cross-departmental visibility that avoids taking a stab in the dark for days. But how can such a tool be built? Furthermore, would it be yet another tool the actors have to feed with data? Administrators, for example, are already logging most of their activities to a CMDB and do not want to be burdened with yet another logbook.

Leon draws three possible integration scenarios on a whiteboard, as shown in Figure 8-25. They adhere to the general Enterprise 2.0 rule that tools must be put into the flow of daily working practices.

The intention for the change management microblog is certainly to implement a dedicated application with a database holding all the posts and a front end for submitting blogs and searching. This application is the middle pillar in Figure 8-24. Then there are three options for integration:

In addition, it might be possible to pick some low-hanging fruit. Bank4Us had to invest heavily in features that serve regulatory compliance. Some of those regulations impose the requirement to capture each change, including what was changed, who did it, and when. These data are already collected in certain areas; they could be reused for the microblog.

Sarah finds Leon’s answers quite convincing and suggests seizing the opportunity. Dave Callaghan’s anger about the recurring troubleshooting marathons has not yet evaporated. Maybe he is in the mood to spend some money for a proof of concept?

Summing it up: Assessment by the EA Dashboard

“Never touch a running system” is a valuable piece of advice, and most people feel uncomfortable intruding into such a system; they are afraid of opening a Pandora’s box. But changes, both structural transformations as well as tunings of the status quo, are a mandate to keep the system viable in an environment with varying demands.

Enterprise architecture wants to be a scout and companion in touching a running system, and Building Block 6, Participation in transformation, shows how Enterprise 2.0 can be an ally in fulfilling this role more effectively.

Table 8-3 lists the EA activities with the closest relationship to the application examples of ACM and CMM. It also marks the social software functionality the examples rely on, with a solid bullet highlighting the most crucial ones.

The benefit of EA 2.0 in guiding transformation is summed up in the Dashboard assessment in Figure 8-26.

The major benefit of the ACM is to enforce that the big picture Design (with an uppercase D) is consistently implemented in the nitty-gritty design (with a small-case d). It therefore helps avoid the notorious friction between what is written in the high-level specifications and code-level reality and draws the Perspective gauge away from Cloud Cuckoo Land.

The CMM effect is more on the Transformation gauge. It does not change the pace of change, but it helps that the organization actually can manage this pace. Therefore, it takes away some negative side effects and risks that people experience on a permanent construction site.