Enterprise Architecture is Nothing Without Adding Value

Alan Inglis has written an excellent blog on Enterprise architecture is nothing without delivery where he gets under the covers of EA to describe the relationships between some of the activities we do day to day. Alan says -

"Architecture is about doing the right things right."

Absolutely Alan! Nice elevator pitch.

When reading Alan's blog what made me a little uncomfortable was the apparent decoupling of "Architecture" from "Management"...

As EA's we look to the Enterprise (organisation/business unit) to understand its business, its business processes and how its IT assets are supporting them. We should also have a solid understanding of the Value Chain within the Enterprise, so as to best understand where Value is being added either directly or indirectly.

For EA to work effectively it has got to be embedded into the boardroom. The CxO's must be confident that IT will enable the business to meet its objectives and support the EA function. For this confidence to be build within the boardroom the Enterprise Architecture value contribution must be known to the board members.

Some examples that spring to mind:

Proactive Contributions (upward looking)

• Cost Reduction
• Consolidation
• Data Centres
• Systems
• Applications
• Decommissioning (Switching things off!)
• (Business) Differentiation
• IT Innovation
• Cost projection
• Do the CxO's understand the full life cost of the programmes
• Do the CxO's understand the ROI
  

Reactive Contribution (downward looking)

• Project/Programme Cancellation
• EA's spot a project is going bad...
• Quality Assurance
  
• Technical Deep Dives
• Solution delivered matches requirements
  

What you probably don't want (as an EA) is your CxO telling you they want 20%, 40% or 80% reduction in IT spend: As an Enterprise Architect you should have a strategy in place which means the Enterprise IT service offered to the business is efficient as practically possible.

So, getting back to Alan's blog, my extension to the elevator pitch would be -

Enterprise Architecture is nothing without adding value and assuring delivery; sometimes stopping delivery - for the right reasons - is a good thing...

Enterprise Architecture C-Suite Elevator Pitch

In trying to work through the C-Level elevator pitch for Enterprise Architecture I've been reading the eponymous books by Michael Porter, "Competitive Strategy" and "Competitive Advantage"; where Porter defines the concept of the Value Chain. While reading I had one of those life changing "light bulb" moments:

Enterprise Architecture is about the identification and realisation of Competitive Advantage

The basis of the hypothesis?

Competitive advantage is obtained by having an efficient and optimised value chain. A value chain (at a high level) exists between the supplier and customer, consisting of:

• Direct Value Activities
• Indirect Value Activities
• Quality Assurance

Direct value activities are (stating the obvious) directly contributing to the value of the product (manufacturing etc). Indirect value activities are (again stating the obvious) indirectly contributing to the value of the product; an example being machine maintenance. Quality Assurance is ensuring that activities are performed correctly, to a greater or lesser degree. A value chain is a complex entity within an organisation where activities can have many connections between them and other activities; for example, a more stringent quality assurance process can reduce the cost associated with a direct value activity. In practice this example could be where the more stringent quality assurance of the component inputs to a manufacturing process results in less errors & defects during manufacture.

Identification of Competitive Advantage
Competitive advantage comes from many sources and is driven by the corporate strategy. For example, if the corporate strategy is to transform from a generic supplier in its sector to one of specific product differentiation, then competitive advantage will arise from being able to disaggregate business capabilities from the generic to the specific. In this example Enterprise Architecture can enable this by identifying the business services that are required to realise the corporate strategy and identify those that are redundant. These business services may nor may not be supplied or supported by an IT function.

Realisation of Competitive Advantage
Realisation of competitive advantage is defining the corporate implementation strategy, putting the strategy into action, transforming the business over time. Enterprise Architecture can support this, for example, by introducing EA best practices improving the effectiveness of quality assurance.

Does the hypothesis hold? I believe at first inspection this is absolutely the right direction to be taking Enterprise Architecture into the boardroom, as always the devil is in the detail. Sadly I also believe that Enterprise Architecture is now so closely linked to an IT function that barriers will be raised to the "Enterprise Architect".

The Shape of the CTO

I stumbled upon a set of resources for CTO/CIO while researching for a Point of View. On this site there is an excellent paper by Robert Smith on the "5 PATTERNS OF THE CHIEF TECHNOLOGY OFFICER" which describes the differing roles a CTO could take, which are:

• Genius
• Administrator
• Director
• Executive
• Advocate

I'll precis my reading of these roles and I propose an extension to these shapes in the form of a CTO "Shape". On reading Robert's paper I was struck by the number of CTO's I've had the pleasure of working with in the past who operated in one or more of Robert's patterns. By combining a rating for each of the patterns you can create a shape of the CTO which should help you structure any proposals (or pitches).

The Patterns

A Genius CTO (I would prefer the term Champion) would normally be found in a new company or business unit where there is a "research" product being commercialised. A Genius CTO or the organisation would have the following characteristics:

• Technology Revolution
• Visionary
• Belief in Product
• Unique Product
• Maturing Product

The Genius CTO was typical of the .com boom.

An Administrator CTO (may be called IT Director) is typical of the public section and will normally have the following characteristics:

• Defends the corporate budgets on IT spend
• Supplier negotiation / management
  
• Separates marketing claims from technical reality
• Looks to reduce IT spend for same service level
• Appreciates the technical aspects as well as administrative

A Director CTO (may be called director of R&D) would typically have these characteristics:

• Looks to build an environment for others to deliver
• Talent for organisation
• Manages exceptional people
• Bridges research and strategy within an organisation
• Accountable for research contribution to the bottom line
• Separates ideas with great commercial potential from those that are technically challenging but do not contribute to the bottom line
• Matches research plans with those of the broader business strategy

An Executive CTO would typically have these characteristics:

• Large organisation
• Integrated into the executive board and relied upon to manage and direct the company
• Fosters the exchange of information between research, manufacturing and service
• Measures innovation & research against contribution to companies revenue and its competitive advantage

An Advocate CTO (may be the CIO) would typically have these characteristics:

• Focused on how the customer perceives the organisation
• Looks at how the customer interfaces with the organisation
• Typical of retail, service or public sectors
• Does not look to create new technologies, focus on selecting technologies to combine to deliver business capability

The Shape

By scoring selected CTO's I'd worked with in the past against each pattern you can determine the shape of the CTO.

Once the shape of the CTO is identified, the shape should assist you in understanding their agendas and where they are most likely to be sensitive to your pitch.

Value of Enterprise Architecture

I am constantly trying to refine the EA pitch and while doing some research I came across this interesting article. There are some interesting ideas in here that I need to digest.

I recently had a coffee with the CEO of a global manufacturer/retailer; we've known each other for a number of years but never really talked work. What struck me was how little he was aware of EA or how it could help him: It seems we still have some barriers to the boardroom!

Principles & Requirements

I had a role as Chief Architect on a large UK Government project. The project was in dire straights prior to my joining with significant projected cost overruns in the order of tens of millions of pounds. Investigating why we were failing lead me to only one conclusion - Requirements.

As an architect it is often easy to point at the requirements as being the source of all your woes, however; in this case it was definitely justified. We had multiple requirements teams gathering requirements from the customer in different ways, documenting the requirements in Use Cases (in different ways) - I wanted to scream - leaving the customer completely unclear what they were asking for and what they were required by legislation to do. When we started to look at the costs within the project we could not even identify the source of the requirement. [I'll get onto this soap box in another post...]

When I sat round the table with the Programme Director trying to identify a strategy to get us out of the mess I realised that the PM team could not grasp the importance of Architectural Principles. This lead me to think about how we were communicating them to our stakeholders. I hit upon this simple phrase:

When identifying an enterprise solution we take into account the business (functional) requirements and non-functional requirements but also the constraints [principles] on the solution. Changing the requirements or changing the constraints can affect the solutions and their costs.

The Programme Director understood, and the PM team quickly followed, the "solutioning challenge". I've now used this approach on a number of subsequent projects and find the PM's quickly understand the importance of exploring the constraints (principles) to see what options there are to stretching them. This got me thinking about how we should capture and document Constraints or Principles within an Enterprise Architecture...

Constraints could be loosely categorised as weak or strong. A weak constraint being one that is easily challenged and overcome, having little business benefit to the solution or the Enterprise. A strong constraint is one that is difficult to challenge and one you unlikely to overcome for a number of different factors.

Some examples of high level constraints [nee Principles] would be:

• Business Strategy
• Defines where the Enterprise would like to be
• A strong constraint
  
• Architectural Strategy
• Tactical solutions or approaches are often taken if they are perceived to be cheaper or easier to deliver to the deadline reverting to the AS-IS Architectural Policy
  
• A weak constraint unless the solution was key to the business strategy
  
• Architectural Policy
• Defines the constraints within the current AS-IS Enterprise Architecture
• Products, Technologies, Approaches
• A weak constraint, but may require considerable effort to introduce new products or technologies onto the estate.
  
• Security Policy
• Defines the approach to Security within the Enterprise
• Has far reaching consequences into the Enterprise and often shapes the AS-IS architecture
• A strong constraint

An example Security Policy [Principle?] could Enterprise conformance to the UK Government Security Guidelines. This policy/principle/constraint could introduce significant cost into the solution; removing the cost by challenging the constraint can only be done with good understanding of the risks that may be introduced into the Enterprise. Acceptance of any change to this constraint is going to be a long drawn out process that could significantly affect the timescales without any guarantee of successful change.

So bringing us back to the original "solutioning" challenge:

• Within an Enterprise Architecture (EA) there must surely be a generic set of requirements sourced from the Principles underpinning the EA that should be applied to each new programme or project
• EA Governance should be measuring compliance of solutions against these requirements
• If an EA has an architectural requirements catalogue then specific areas of a constraint could be challenged when costs can be clearly attributed to the requirement
• Having a specific challenge to a part of a constraint should significantly reduce the architectural effort required in exploring or stretching the Enterprise Principles [Constraints!]
• The EA Requirements Catalogue should be a major tool in explaining to the business stakeholders solution options and costs

So when you're on a programme or you've been engaged to help with the Enterprise Architecture have you been able to understand and communicate the constraints of the business and architectural principles? Have you been able to have traceability of solution costs back to the constraints? If so, how have you achieved this?

Cheers,
Andy