Has EA gone for a Burton?

@mikerollings, an analyst with the Burton Group, invited Brenda Michelson to check out his free report Enterprise Architecture is more than Engineering, so I thought I'd take up his invitation as well.

Mike Kavis had started the discussion with a comment on Twitter: "Everybody is struggling with the value of EA for us little guys while I see it each day." In reply, Brenda had suggested that the problem was "many equate EA w/jumbo frameworks and rigid governance, rather than set of values and practices for capability delivery". This was what prompted Mike Rollings to issue the invitation.

Meanwhile, Aleks Buterman claims to have a "secret sauce to measuring value of EA" but won't let anyone see the recipe. I think this is a pity, because I believe a credible measurement formula needs to be open, transparent and calibrated on a range of different organizations. I hope he's working towards making something public.

Before we look at Mike Rollings' own report on EA, let's take a quick look at his criticism of Gartner, provocatively entitled Gartner wakes out of an EA induced coma ... (11 August 2009)

"Thank you Gartner for validating my claim that prevailing wisdom about EA is washed up and the pursuit of building an EA admiration society is not the predominant goal of EA.  Thank you for further illustrating that living in a mythical world where EA is king is just dead wrong."

And he continues with a plug for his own firm

"Want a new approach for enterprise architecture? Read Burton Group's EA research."

So I did (see edited highlights below). Mike's report identifies three familiar problems, and then makes four fairly bland recommendations. Is this really a new approach? Unfortunately, there is a "disconnect" (one of Mike's favourite words) between these two sections, so the recommendations don't demonstrably deal with the problems. (Indeed, readers with real experience of EA may see ways in which Mike's recommendations might make some of his problems worse. For example, there are several plausible arguments for having an eclectic approach to EA, but it isn't clear how this is going to solve the problem of disconnected EA artifacts.)

While Mike's understanding of EA problems appear to be underpinned by his adhoc observations of EA in practice, there is no sign that his recommendations are based on anything more than common sense. Therefore nothing to stop him, when he is arguing with Gartner, coming up with an entirely new set of recommendations (see below).

In my opinion EA is in crisis, and it needs a lot more than disconnected recommendations based on common sense and/or prevailing wisdom. More than engineering perhaps, but where is the value proposition for Enterprise Architecture?

---

Edited highlights of Burton report

Problems facing EA

• EA has minimal influence. I have spoken with teams that could not gain traction - their artifacts were disconnected from each other and lacked relevant guidance. I have also seen beautiful architectures ... that go unused.
  

• Lack of participation and commitment. A lack of participation can fuel and be perceived as the ivory tower syndrome, which is a natural outcome of organizational isolation.
  

• Mismatch with the domains of the effective CIO. Most EA programs are heavily skewed towards a single domain: implementing and managing technology.
  

Burton recommendations

• Avoid using frameworks like a precise cookbook for architecture. A variety of methods (unspecified) should be used to capture, communicate and share design information. Enterprise architects employ both manual and mechanical tools in a purposeful way.
  

• Align with your organization's operating model. The operating model is fundamental to the business. Effective EA programs align with the operating model and do not over-reach the level of standardization or integration determined by the business.
  

• Be results-oriented. Successful EA programs are action-oriented and help get things done. People understand how the EA program works. They also understand the contribution that EA team members make as participants in other IT processes.
  

• Do not settle for comparisons: Understand what needs to improve. Maturity assessments can be very elaborate. At a minimum they should evaluate the following EA program characteristics: Business Alignment, EA Program Oversight, Communication and Change Leadership, and Governance. By examining these characteristics with an open mind toward change, an improvement plan can be created to improve EA related outcomes.

New recommendations (Mike Rollings via InfoQ, 26 August 2009)

• Rule-Breaking: If rules are being broken it can signal outdated thinking and the need for something different.
  

• Entrepreneurial: Value of IT comes from being transparent about your business contribution.
  

• Self-Educating: Embrace varying ideas, collaborate vigorously and respectfully, assure that you tap into the variety of perspectives that exist. 
  

• Bonding: The lack of influence is probably a main cause of your EA coma.
  

• Visionary: Be a leader, be a team player, participate and collaborate.

---

Update: Burton Group gone for a Burton

The Burton Group was acquired by Gartner in January 2010. Mike Rollings is now a Gartner Analyst.

Economics of agility

@andygreenawalt says he hasn't seen much on the economics of agility. "Open source breaks $ vs security battle. Investment impregnation kills agility."

Andy's comment arose from a discussion of agile security. See my article Agile Security for SOA (CBDI Journal, June 2005).

More generally, the economics of agility is critical to the business case for SOA, and a few of us have sometimes called it the SOA Sweet Spot (March 2007). See my article on the Agile Business Process (CBDI Journal, July-August 2007)

Looking around, I also found some work by Marc Rix called Bottom-Line SOA: The Economics of Agility (April 2007). See comments by Alastair Bathgate, Bill Barr and Gary Smith, with Marc's response.

And back in 2004, Stuart Robbins wrote something on the economics of agility for grid management (pdf).

But compared to the huge amount about the economics of scale (sharing, reuse), that's not much is it?

Organizational Memory

Are social networking tools the solution to improving organizational memory (asks @EffectiveCIO Chuck Musciano)? Chuck's blog Legs and Memory suggests a link between memory and efficiency: "Forgotten items create more work, both at home and on the job."

Now that would be easy enough if nothing ever changed, and if last year's best practices still worked. But as Chuck points out, formal guides and detailed documentation fail because of continuous change. There is a tension between efficient adaptation and effective adaptability.

So Chuck argues that organizational memory is best retained in the heads of the people in the organization. And because captured organizational memories fade rapidly over time, you must reinforce your organizational memories, by constantly revisiting and updating them.

What's the role of social networking tools here then? Chuck doesn't believe that these tools are yet up to the job of real-time knowledge capture, and falls back on the old favourite - finding the person who knows what we need. Better than nothing perhaps, but way short of what is needed.

---

What is needed for organizational intelligence is the ability to use organizational memory without being controlled by the past. In his post (some) rules are meant to be broken, Brett Miller makes this point very well.

You can see this in the way many organizations apply the idea of “best practices”: capture past practices that worked and apply those practices, as is, to future situations that are similar. While this works fine for what I call “information” processes - and is a critical step in helping any organization improve - it is not appropriate for “knowledge” processes. ...

... This is not to say that past experiences should not be exploited in creating/acquiring new knowledge. Except for the rarest of occasions, most new knowledge created today is derivative of something past. It is important to know what has come before and learn from the successes and failures of others. The rules that come from those past lessons then become the framework for the future.

But of course organizational memory does not only consist of rules (best practices), but all sorts of other knowledge (including evidence, interpretation and stories) that may be relevant to developing next practice. A lot of this knowledge will surely be maintained in electronic form, not just in people's heads, some structured or semi-structured, using a broad range of social software.

Furthermore, evolving practices (organizational learning) will typically require collaboration between different people across the enterprise, and we may reasonably hope for software tools to support this learning.

Once upon a time, information systems maintained a clear distinction between highly structured data (in old-fashioned databases) and loosely structured information (in a wide range of formats, including Office). But we now need to find new ways of integrating this information to support the intelligent organization.

Enterprise Suffix - Companies as Categories

@tetradian Tom Graves is annoyed at Enterprise 2.0. He (rightly) complains that the term as defined by Andrew McAfee refers to software, and tries to construct an alternative definition that is more business-oriented.

While I agree with his complaint, I am not convinced that a business-oriented definition of "Enterprise 2.0" is a worthwhile exercise. The "2.0" suffix is inextricably linked to the software paradigm; it is a metaphor for strict version control, and really only makes sense to software engineers and dictators. To produce the Third Reich (or as we should now call it "Reich 3.0") required a massive amount of centralized control and alignment (known as Gleichschaltung).

Software engineers who want to sound cool often use names instead of numbers. Apple operating systems are named after large cats, so we might have something like Enterprise Snow Leopard. (Thanks to Ron Tolido.) Microsoft plays this game as well - see my post on Google and Longhorn.

Software people may describe enterprises in terms of version numbers, but how do business people describe enterprises? Usually by comparing with something else. Listen to how entrepreneurs bid for venture capital. "It's going to be like eBay with a dash of vodka." "It's going to combine the innovation of Google with the popularity of er Google." In other words, they tell stories and paint pictures.

At any given time, there are a few companies that everyone wants to emulate - not just in terms of market share and profit, but also in terms of the internal management and organization - typically based on descriptions in the popular business literature. One of the early classics of this genre was Peters and Waterman, In Search of Excellence, which held up several American firms for admiration and emulation. (These recommendations look really dated now; and as Jason Cohen points out, Business Advice is Plagued by Survivor Bias.) In the heyday of quality management, many people tried to emulate Xerox and Motorola. More recently, Joshua Cooper Ramo, in a book called The Age of the Unthinkable, identifies Google and Hizb'allah as two of the most innovative organizations of our time.

Therefore if we must have an enterprise suffix, and if we want this to be meaningful to business people, let's use well-known companies as the categories. So if you want to emulate Google, then you need to implement Enterprise-a-Google.

Not perfect I agree, but anything's better than these dammed version numbers.

The Calculus of Cost

@fbjk2000 (Florian Krueger) poses a set of questions about costs, under the heading Review your calculus of cost. The questions are fair, but the heading is wrong: Florian's questions are all about reviewing cost, and nothing about the calculus of cost.

Cost review looks either at the total cost (is this too much for customers to bear) or at individual cost items (are we paying too much for this item)?

Cost calculus looks at how the total cost is composed from individual cost items, understanding how costs are added and subtracted and multiplied, getting an appropriate balance between fixed costs and variable costs, clustering expenditure to achieve cost synergies, and so on.

Here are some examples

• In a traditional high-volume non-volatile business, cost reduction can be based on economies of scale, with high fixed costs and low variable costs.
• In a volatile business, it may make more sense to reduce the fixed costs and accept higher variable costs.
• Purchasing several different items from the same supplier reduces transaction costs and allows bulk discounts to be negotiated, but may not achieve the lowest price for every item.
• Allocating costs to a given project can yield widely different results, depending on the formula that is used.
  

For any reasonably large business or IT operation, questions like these require non-trivial mathematics. And you shouldn't use words like "calculus" unless you are prepared to do that.

Is this just quibbling about semantics? Not at all. Business people may worry about costs, but business analysts and business architects need to pay attention to the structure of costs rather than the tactical details.

Loose Coupling: Innovation and the Web

"Cosy social networks are stifling innovation", according to an article in the New Scientist (5 August 2009).

This is a familiar argument in a new context. It has often been argued that corporate culture can inhibit innovation, and that groups responsible for experimental products and processes tend to perform better if they are put into a separate organization unit at some distance from the main offices. In recent years, many companies have set up R and D units in special science parks, co-located with similar units from other companies, usually with links to a nearby university. This is essentially applying architectural thinking to the geographical location and distribution of certain classes of capability, and reflects a common belief in the importance of these factors.

But interaction and clustering is nowadays much less dependent on physical geography, and much more dependent on virtual online communities and networks. The New Scientist article quotes Viktor Mayer-Schönberger of the National University of Singapore, who argues that today's software developers work in social networks in which everyone is closely linked to everyone else. "The over-abundance of connections through which information travels reduces diversity and keeps radical ideas from taking hold."

What Mayer-Schönberger sees as an over-abundance of connections is actually another form of tight coupling. If we want to build the capability for radical innovation, we need to create a decoupled space to support a loosely coupled knowledge cycle. Which means careful attention to the effects of social networking and organizational intelligence.