Selling Enterprise Architecture Through Analogy

I use analogies a lot – in my teaching, consulting, and just about everywhere else!  By no means a panacea, a well chosen analogy can make things “click” for people who might otherwise not “get it.”

“Selling” Enterprise Architecture

I’ve blogged frequently about Enterprise Architecture (and its subset, IT Architecture) because I believe it is a fundamental, literally, foundational discipline for business enablement through IT, and yet is woefully under-served in most organizations.  One reason is – it is tough – balancing competing needs for standardization on the one hand, and innovation on the other.  The other reason is IT architects are often poor  business communicators, and are inept in “selling” the effort necessary to do things in an “architected” way.

Architecture and the New York Subway

My temporary relocation to Manhattan has allowed me to experience the New York subway (and bus) system more fully than ever before – and it makes a great analogy for Enterprise Architecture – or its lack thereof!

New York’s public transport is a gem!  No, it’s not world class (try Singapore’s or the Washington DC Metro system for examples of clean, quiet, fast systems) but it works.  However, I have quickly become aware of many idiosyncrasies of the New York subway.  Certain stations (e.g., 14 Street, 59th Street-Columbus Circle, Borough Hall) where you need to change lines, don’t seem to ‘line up’ properly – you have long underground walks, underground shuttles, or, in some case, have to surface to street level in order to go back down to the different line (these are aptly referred to as “station complexes” and complex they are!)  Some connections between lines that should be simple, aren’t!  It felt to me as if there wasn’t a coherent architecture to the subway system – so I did a little research to find out why.

Three Subway Architectures!

In 1898, the City of Greater New York was formed from several counties and their constituent cities, towns, villages and hamlets.  The City recognized the need for an underground subway system, but also realized that no private company would provide the significant capital required for such an infrastructure.  The City decided to issue rapid transit bonds and contracted with the Interborough Rapid Transit (IRT) to build and run the subways, sharing the profits with the City.  IRT opened the first NY subway in 1904.  Meanwhile, the Brooklyn-Manhattan Transit (BMT) was building and buying up the Brooklyn elevated rail lines.

In 1913, the city embarked on a “Dual Contracts” initiative, engaging the private IRT and BMT to expand their systems.  By the 1930’s, the City realized that the independent IRT and BMT were making handsome profits, so the City of New York created its own third system, the Independent Subway System (IND).  The IND introduced yet a third architecture, so that the IND, IRT and BMT were competing with each other.

The Challenge of Integration

This competition led to overlapping services and different standards (such as carriage width, carriage length, train stop safety mechanisms).  In 1940, the City took over the transportation assets of the BMT and IRT under a program called Unification.  However, to this day, due to different tunnel diameters, curves and clearances and the different rolling stock, asset utilization is sub-optimal, and for passengers, navigating the subway system can be challenging and inefficient.  To eliminate overlapping and redundant services, certain stations and even some tunnels had to be closed.  Also, costly “interfaces” had to be built between the three separate systems in the forms of tunnels, walkways and shuttles.

If New York City Were a Business?

Imagine the City of New York as a business, and the IRT, BMT and IND as separate divisions.  Imagine that each division wants to create its own IT organization and IT capabilities.  Imagine there is no overarching architecture or standards.  Now imagine, as a business you recognize the synergies between your three divisions, and want to integrate and leverage as many shared services as possible.  What do you find?

  1. It’s incredibly costly to achieve integration because your three IT infrastructures are incompatible.
  2. You discover you have excessive redundancy across the three IT infrastructures.
  3. The cost of keeping the IT infrastructures running is eating into your operating margin, and yet the capital cost of rationalizing the infrastructures is prohibitive.
  4. With eCommerce and Enterprise 2.0 possibilities, you need to collaborate more effectively across divisions than you do currently, but none of the three IT infrastructures will support that type of collaboration.
  5. You ask your CIO, “How could you let this happen?” as you look for a replacement!
  6. Your CIO points to the chief IT architect and blames him for doing an inadequate job of convincing the IRT, BMT and IND divisions of the need for an overarching architecture.
  7. Your chief architect commits suicide (by jumping in front of a subway train?)

The Value of Enterprise Architecture

So, what were the costs of the lack of a unifying architecture to the NY Subway system?  Had the IRT, BMT and IND followed an overall architecture and set of standards, how much time and money would have been saved compared with the “each go it alone” approach?  That is the value of architecture.

What analogies can you use that will resonate with your senior business executives to sell them on the value of Enterprise Architecture?

The Downside of Standardizing Too Soon

In all fairness, I must reference the fact that choosing standards too soon can and does stifle innovation.  The beginnings of the New York Subway occurred while there was a fierce competition between Nikola Tesla’s Alternating Current (AC) and Thomas Edison’s Direct Current (DC) systems.  DC won out (for good reasons at the time) but modern solid state technology and advances in electric motor and switching technology mean that AC would have led to a simpler, more flexible and less costly subway system construction.

Image courtesy of Blog Them Out Of The Stone Age

Reblog this post [with Zemanta]

Web-Oriented Architecture: From Push to Pull – So Very 2.0!

Dion Hinchcliffe’s excellent recent post on Web-Oriented Architecture (actually, this is his latest in a series of posts on this topic) reflects an important shift in thinking around technology architecture and componentization.  This is the shift from push to pull approaches to change – a shift I’ve covered from from time to time in this blog.  It is, I believe, inherent in the evolution from “1.0” to “2.0” (as in Web 2.0, Enterprise 2.0, and so on.)

I’ve posted previously on the shift from IT Architecture to Enterprise Architecture and how this takes you from an IT-out to a business-in approach to design.  I’ve since expanded on this idea in my post about moving from Enterprise Architecture to Ecosystem Architecture).   Our research last year into SOA showed that most companies try to go about SOA the wrong way – IT-out rather than business-in, and as a technical standards rather than a business capabilities issue .  Our research report identified  hope then was that IT professionals would get it, and leverage SOA appropriately.  In retrospect, that was probably an unreasonable hope.  Instead, WOA is evolving naturally from the mélange of emerging standards and architectures.

One of the most powerful attributes of the 2.0 world is its outside-in, bottom-up “pull” nature (as opposed to the 1.0 inside-out, top-down “push.”)  I think that WOA (as a manifestation of SOA) is working because it is emergent, and is inherently “pull” oriented.  Dion captures this beautifully in this graphic.

Note:  Thanks to Brian for his photo from the 2005 Burning Man extravaganza.

Business Implications of SOA

It’s time (perhaps even long overdue!) to tackle the thorny topic of Service Oriented Architecture.  I’ve been preparing an executive presentation on this subject, drawing on one of our multi-company research projects, so it’s fresh in my mind.

The research was focused on business implications of SOA, as this was a perspective and context that the research team found was missing from many of the early forays into this space.  Certainly, there are many worthwhile experimental and pilot projects going on in the name of SOA.  These are mostly useful learning activities, but unfortunately, the way many of them are framed, they may well be missing the most important aspects of SOA, and the dramatic positive impact SOA can have on IT organizations and the businesses they serve.

The biggest mistake begins when SOA is perceived to be a technical issue, and is approached as a largely internal (to the IT organization) matter.  Buried in the bowels of IT, most SOA initiatives are likely to miss the point, and fail to achieve their full impact – or, at least, take far too long for that impact to be realized.

Let me begin with the major business implications our research identified.

Over the next few posts I will take each of these points in turn and expand upon them.

1. A Market-Driven Ecosystem is Evolving

I’d like to illustrate this point with a quote by Eric S. Raymond from his 1999 landmark paper, The Magic Cauldron:

“…software is largely a service industry operating under the persistent but unfounded delusion that it is a manufacturing industry.”

Disruptive forces are rapidly impacting the traditional business model of software vendors.  At the same time, thanks to the Open Source movement and changing perspectives of what is “proprietary,” companies are re-thinking how they go about automating business processes.  Of course, the reality has always been that companies never actually want to purchase software – they want the capabilities that have traditionally been provided through purchased software.  If they can get those capabilities faster, at lower cost, with greater efficiency and flexibility, they will do so – at least, once the fear of shifting to a new business process design and automation paradigm has abated.

The “magic” behind SOA lies in the underlying standards and protocols that have grown out of the Internet – standards such as XML, ebXML, SOAP, WDXL, SAML, WS-Security and BPEL.  In addition to these standards, methods such as Object Oriented Programming, with its concepts of loose coupling, autonomy, abstraction and composability, along with the principles of “service orientation” at long last bring the promise of reuse and “plug and play” modularity to reality.  Together, these standards and methods provide for loosely coupled, coarse-grained, business-centric, reusable services.  Such services no longer have to be “hand programmed,” or even “assembled” from an in-house library of building blocks.  Now, and increasingly over time, they can be procured on the open market – often for free!

Think about the implications for an IT organization, circa 2017 (this blog’s title) when there is a thriving ecosystem of business services – from tiny micro widgets for activities such as name and address checking, to sophisticated business processes such as purchasing and supply chain management.  Imagine, for example, that someone in your IT organization had programmed a widget that would make it easy to show all you customer locations as pins on a map, with the size of the pin representing the volume of business you conducted with each customer this month.  Imagine further that an IT savvy business manager wants just such a capability.  How is he going to know you have one?  Chances are, he’s going to use Google (or another search engine) and locate such a widget in less time than it takes to make a cup of coffee.  The reality is that, at least today, the web is far more easily searchable than your internal object library.  And, of course, my hypothetical case that someone in your IT organization had already created such a widget is unlikely, so we are heading from a reality where:

1. Business users will meet their own needs by “pulling services from the cloud” rather than asking their friendly (but way too busy!) IT professional.

2. A vast supply of business widgets will become available to these business users.

Now, I don’t believe this is bad news for the IT profession – quite the contrary, it is great news!  You see, at the risk of stating the blindingly obvious, not all business services are of equal value.  We can help break down types of services based upon their contribution to value using ideas first articulated by Professor Noriaki Kano in the 1980’s, through what is known today as the Kano Model.  Many services are simply ‘table stakes’ – they fulfil basic needs – they have to be done, but they don’t differentiate you in the marketplace.   Name and address validation, credit checks, and so on are table stakes types of services.  Other services go beyond table stakes to meet performance needs.  They can, if done really well, provide customer value above your competitors.  Finally, there are services that can literally “excite” the customer – deliver something they were not expecting, and don’t get from your competitors.  These are the highest value, often innovative services that differentiate you in the marketplace.

So, the big opportunity, made possible through SOA, but not an automatic byproduct of using SOA unless you plan for it, is to focus the internal IT organization and resources on “exciter” services, and let the open market provide the basic and performance services.  Over time, the market will provide faster/better/cheaper “table stake” and “satisfier” services than you can or should provide internally.  Of course, I’m taking an overly simplistic position on this – focus the IT organization on differentiators, and obtain all other types of services on the open market if you can.  I recognize that life is not that simple.  But as a direction to follow, and a culture to establish, this perspective will take your SOA efforts in a potentially very different direction.

The challenges in moving in this direction are significant – not because of the technology, which is evolving rapidly, but because of “unwritten rules” that drive behavior.  (See earlier post on Unwritten Rules.) Typical ‘unwritten rules’ that conflict with this powerful new direction for service provisioning include:

  • People are measured on the performance of their function, not the total enterprise – for software developers, ‘performance’ is typically equated to ‘writing code.’
  • Taking a risk that has a bad outcome can be career-limiting.
  • Working with ambiguity is heroic, clarifying ambiguity is non-rewarding.
  • Satisfying your boss is more important than creating a great customer experience.
  • Implying that someone else does something better than us is taboo.

The real trick of getting the most out of SOA – indeed, exploiting the transformative powers of SOA, will be in overcoming these (and similar) unwritten rules and other more structural impediments such as IT funding models (that tend to be project based and unfriendly towards infrastructure development) and governance models (which often position IT architecture governance as a policing rather than enabling activity.

We will pick up on additional business implications of SOA in subsequent posts.

You Know You’ve Reached Level 3 When…


Back in mid-December, I posted “You Know You’ve Reached Level 3 When…”   As the BSG Alliance multi-company research project that has been examining Reaching Level 3 Business-IT Maturity shifts gears from its research to its reporting phase, I want to revisit that headline.  Here are some ‘one-liners’ that are being discussed in today’s WebEx session for the participating companies:

You know you’ve reached Level 3 Business-IT Maturity when…

  • There is no separate IT Governance structure – it is converged with Business Governance
  • There is no separate IT Portfolio – it is integrated into the Business Portfolio
  • There is no separate IT Strategy – it is integrated into the Business Strategy
  • There is no separate IT Architecture – it is a component of the Enterprise Architecture
  • There are no separate IT Relationship Managers – Relationship Management is a widespread and diverse Role

How do those statements feel to you?  Are you already there with any of them?  All of them?  If you reached those conditions, how would things be different around IT decision making and value extraction?

Did You Accidently Outsource Your Enterprise Architecture?

I’ve referenced Enterprise Architecture several times in this blog, and see it (or lack thereof!) as a common “sticking point” (see, for Example, Enterprise Architecture and Level 2 Sticking Point) as it’s one of those things that does not naturally “grow” out of less mature practices (IT Architecture, for example) but takes a different twist (bottom up to top down, and inside-out to outside-in, for example).

I’ve found myself in conversations with a couple of clients this year who struggled particularly hard to grasp what I meant.  I then discovered that when they had shifted to SAP as their major Enterprise Software package, they had essentially said, “Whew!  Now we are going to SAP, we can just adopt their IT architecture and stop messing with all that stuff!”  Essentially, they had “outsourced” their IT Architecture, which had the unfortunate side-effect of masking them from the distinctions between Enterprise and IT Architecture, such they had therefore essentially outsourced their Enterprise Architecture. 

I am describing a couple of extreme cases I came across this year, but in reality, I think this phenomenon is not uncommon.  I’m all for outsourcing selectively, but it is essential to take care not to accidentally outsource important management disciplines along the way!  To push my frequent analogy of “crawl, walk, run” a little too far, it’s as if the crawling baby, about to make her first tentative walking steps, is intercepted by a parent with a push chair who says, “Baby, you don’t need to walk – let mummy push you wherever you need to go.  One day, you’d be able to run everywhere, and be pleased that you saved your feet!”

Let me take this opportunity to wish my readers Happy Holidays, and a Healthy, Prosperous 2008!

From ‘Supply Constrained’ to ‘Value Constrained’ Business-IT Model

One of the difficult paradigm shifts that tends to trap IT organizations in Level 2 Business-IT Maturity is the notion that business demand must be constrained by IT supply.  Demand always exceeds supply for IT capacity, so the idea (part of the Level 1 experience) is to set a limit on IT supply, then figure out some way of prioritizing demand against that supply capacity.  Sometimes the the constraining mechanism is IT budget, other times it is IT headcount – either way, the net effect is the same – a bunch of work that the business wants won’t get done, and we hope the prioritization mechanism works sufficiently well that the “right” demand is flowing through and getting address, and the “wrong” demand (low business value) is not.  I’ve rarely seen this work well.

If there is a single line of business, at least demand can be prioritized across the business line, and the mechanisms to achieve this are not too hard to implement.  Typically, however, there are multiple lines of business, and while the mechanisms in each business line may work ok, there are rarely effective mechanisms across lines of business.  This leads to all sorts of dysfunctionality, especially as the enterprise matures and shifts towards more of an integrated business, with common and shared process, compared with the more functional and stove-piped model typical at Level 1.

For example, IT resources get “walled off” against business units – sometimes actually being embedded in the unit.  There’s nothing inherently wrong with the embedding – certainly some IT capabilities (such as Relationship Management) work most effectively when they are really close to the business).  However, when analysts, designers, developers, testers, etc. get “walled off” for given business units, they are no longer available to be shared across the enterprise – they creates all sorts of inefficiencies.  And, from my experience, with the best will in the world, and with competent, well meaning people both in IT and the business, demand will fill that available “walled off” supply no matter what.  A result is that lots of relatively low value and non-essential demand gets filled, while high value demand, both within the business unit with the walled off resources, and in the other business units sits in a backlog (at best) or, more typically, just does not get surfaced because people know there is no hope of getting it filled.  A symptom of this is an IT organization with literally thousands of active projects, mostly small, and with a general sense that IT costs a lot of money and delivers little value.  Such an environment presents all sorts of challenges to real business-IT strategic alignment.

The big breakthrough comes somewhere in Level 2 where there is a shift from this supply constrained model to one that is value constrained.  Let me first describe the theoretical end state of the value constrained model – we will explore the practical realities of moving to this model later on.  At the theoretical end point, IT supply is treated as an infinite resource that can flex its capacity on demand – ramp up to meet high value demand, ramp down when that demand goes away.

The key enablers to move to this model (once the paradigm shift is understood and desired) are to:

  • Prioritize demand based upon business value (which has all sorts of implications for business cases, cost and value accountability, value measurement, portfolio management, etc.)
  • Create an agile and flexible supply capability (which typically means there is a robust global sourcing strategy and management model, key partnerships with global sourcing entities are in place, and the IT organization has become focused exclusively on “core” IT capabilities – usually encompassing relationship management, demand management, value realization, business process improvement, innovation, program management, portfolio management and global talent sourcing.)
  • Add an IT Program Management layer over IT Project Management
  • Add an IT Enterprise Portfolio Management layer over IT Program Management
  • Elevate IT Architecture to Enterprise Architecture
  • Implement an effective business-IT governance model to facilitate cross enterprise and cross business-IT decision making.

I will explore each of these enablers in subsequent posts.

Enterprise Architecture, SOA and Service Management

I think the dependencies between EA and SOA are just now really being understood.  I’ve recently been involved in a multi-company research project on the Business Implications of SOA.   Based upon that research, and what I see in the IT shops I get to work with over the years, I believe a strong EA capability and maturity is a foundation for SOA, and that ultimately, SOA will not fulfill its potential without a strong EA capability.  That means SOA falls into the Level 2 sticking point, which is a shame because some of the best value from SOA and related capabilities I believe will come in high Level 2 and Level 3 Business-IT Maturity.

Another dependency we surfaced early in the research is the degree to which the IT organization has itself embraced a “services and processes” organizing logic.  We found that, just as the terminology implies, capability maturity with a broad IT Service Management approach dramatically simplifies SOA deployment.  In fact, if you look at a list of characteristics that define “service orientation” in SOA  they pretty much define service orientation.  The sticking point aspect of the shift to Service Management is that the perspective shifts from IT out, to business/customer in.  Things are packaged as “services” easily discoverable, and fully reusable.  There is good understanding of cost to serve and value of service.   This shift in perspective is challenging – again, you have to shift direction – be sensitive to the Yin and Yang involved in maturing IT capability.