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?

About these ads

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.

Enterprise Architecture and Level 2 Sticking Point

One of the manifestations of the mid-Level 2 sticking point referred to in an earlier post is around Enterprise Architecture (EA).  At the risk of over simplifying, way back, most IT shops had some kind of Technology Architecture (TA) capability – usually focused on selecting and enforcing standards, providing an overall schema and logic for physical hardware, networks, and perhaps delivering technology roadmaps (e.g., what gets retired, what replaces it, how).  Typically, as TA evolves (matures?), there is an increased focus on the information and data domains, and TA becomes Information Technology Architecture (ITA).  Note: sometimes the labels don’t properly align with the reality, so we find Technology Architecture efforts referred to as ITA, but they really do a poor job of addressing the information domain, and ITA efforts referred to as EA that do a poor job of addressing the business process domain.

The next shift is when ITA evolves into Enterprise Architecture - and the really big shifts occur.  One way to characterize this shift is that EA becomes very visible, (compared to TA and ITA’s inclination to be in the background and transparent to the business.  EA surfaces and addresses the big issues around business operating model, and truly begins to connect business and IT in new and powerful ways.  But to my point about discontinuity, the shift does not occur because you work harder or smarter at ITA.  Rather, ITA, which tends to be IT-driven, inside out, as it were, and bottom up (to a degree) morphs into EA which tends to be business-driven (or at least business focused) and top down (to a degree).

So, I think one lesson here is, if you get to be really good at ITA, you are going to have to re-think how you got there, your management structures and organizational implications, and how those must change in order to get from ITA to EA, and get to Level 3.