CIO Dashboard

How To Deliver Enterprise Architecture Value Early

post by Chris Curran on July 13, 2010
Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0

Co-authored with David Baker

How to demonstrate the value of enterprise architecture is a constant question we get from our clients. In fact, a more basic question might be “what is the business value of EA?” We strongly believe that EA should be the way that a business connects its strategy to its technology investment plan - through the use of business capabilities. As good as that might sound in concept, the hard work is in breaking organizational myths and stereotypes.

Our experience tells us that determining the services to launch (or re-launch) first must show tangible value and depends upon current maturity and pain points with the existing EA group and IT organization. Here are several options to show value early.

Launch (or re-launch) Project Architecture Assistance Services

These are great services to improve immediately if the EA organization is young or has struggled to gain the trust of the development organization. Trust must be developed in the trenches, so helping projects make decisions and keep projects on track is a good place to start. Our experience indicates that Enterprise Architecture should spend approximately 60% of its time working within projects, helping those projects get through the software development life cycle. The value here is immediate as there should be a positive impact on the delivery of the new business capabilities (e.g. improved speed to market, improved reliability, etc).

Blueprint a High Priority Business Domain

If an enterprise or business unit strategy exists and especially if there is some kind of external mandate (e.g. regulatory compliance) you may want to launch a blueprinting effort for the affected domain. Completing a successful blueprint often has a snowball effect. Once the business owners see how their goals and objectives translate into IT initiatives, they typically become converts to the blueprinting process. Business value is derived from the impact the blueprint has on the IT prioritization and delivery time frames. IT knows it is working on the right projects to deliver the greatest business value. The most tangible value, however, is through delivery of the projects identified by the blueprint. This circles back to the first option listed above architecture assistance and governance. Keep repeating the cycle.

Develop an Enterprise Core Blueprint

In complex organizations (e.g. a large number of business units / business domains), value can be delivered quickly by identifying the core IT functions that serve as many business units as possible. This requires going through a high level enterprise wide blueprint to understand the use cases that are similar across the enterprise. The future state then describes the reusable technology patterns which can then be sequenced into a roadmap.

Develop a Blueprint For One or More Core IT Capabilities

Some companies may have already identified a handful of core IT services such as master data, data management, application integration, portal platforms, or B2B integration. The EA group can launch a blueprinting effort focused on one of these core areas. This effort requires looking across the business domains to understand the business capabilities that would be enabled by the core pattern, and then proposing the future state technology solution to implement the service.

cc licensed flickr photo shared by Wolfgang Staudt

Share on LinkedIn0Tweet about this on TwitterShare on Google+0Share on Facebook0

Related posts:

  1. Busting 5 Enterprise Architecture Myths
  2. 16 Enterprise Architecture Strategies Learned The Hard Way
  3. Who Needs a Current State Technology Architecture?
  4. How to Assess Your Technical Architecture
  5. Meet the new enterprise architect: the “capability architect”

  • Chris, thanks for this insightful post. Your point for creating a core business diagram is very aligned with the book “Enterprise Architecture as Strategy” which I’m currently reading. I strongly believe this model is the most influential way to get business executives perceptions shifted towards the value of EA.

  • Chris, thanks for this insightful post. Your point for creating a core business diagram is very aligned with the book “Enterprise Architecture as Strategy” which I’m currently reading. I strongly believe this model is the most influential way to get business executives perceptions shifted towards the value of EA.

  • This was a very good post. I’d like to see a followup, however, that goes into how to take the next step and avoid one-off EA activities. For example, creating a blueprint for a high priority business area can have immediate benefits, but now we need to identify the ongoing activities around the blueprint that justifies the creation of an EA team, rather than the funding of a one-time effort to create the blueprint.

  • This was a very good post. I’d like to see a followup, however, that goes into how to take the next step and avoid one-off EA activities. For example, creating a blueprint for a high priority business area can have immediate benefits, but now we need to identify the ongoing activities around the blueprint that justifies the creation of an EA team, rather than the funding of a one-time effort to create the blueprint.

  • David Baker

    Todd, excellent idea. I’ve seen several successful efforts and will put together a followup post.

    Dave Baker

  • David Baker

    Todd, excellent idea. I’ve seen several successful efforts and will put together a followup post.

    Dave Baker

  • Mark

    These are all good and you’re headed in the right direction. Another possibility is to explore and understand how enterprise architecture fits into your organization culture and you can do some mapping to determine what works and what does not. For example, given your particular EA organization maturity, map your capabilities or products and services (e.g. deliverables) to mainstream corporate processes such as strategy, performance, change, project, budget, risk, and portfolio, etc. Examine the current deliverables as compared to those that should be there. In other words, try mapping these capabilities below to your corporate processes and then add your EA deliverables to the mapping – see what happens:
    • Aligning strategic and operational views of business
    • Driving the technology vision
    • Transforming and automating operations
    • Facilitating and governing organizational change
    • Mitigating risk
    • Overseeing investments
    • Managing the architecture
    • Integrating people, processes, and technology

    You will notice the current touch points are important but more important are those touch points and deliverables that are missing. One of the keys is understanding your current capabilities, determining the most appropriate capabilities needed to support the corporate culture and of course a proficiency roadmap to transition your EA group from one stage of the journey to the next.

    Enterprise architecture enables the design and implementation of the structures that link an organization’s strategy with its execution. This vital link captures the organizational strategy as blueprints that include enough guidance and detail for the various parts of the organization to execute while facilitating collaboration and innovation. Enterprise Architects use specialized practices to determine where the company is today, scenarios for where it will be tomorrow, and they provide roadmaps that lead from one stage in the journey to the next:

    Long -Term: Where are we going?
    The Enterprise Architect (as a strategist) provides long term stability to ensure strategies are clear:
    • Creating the operating model and transformation plans
    • Developing strategic technology plan

    Near-Term: How will we make sure we stay on track?
    The Enterprise Architect (as a tactician) facilitates near-term efficiency by ensuring the operating model is flexible:
    • Increasing executive awareness of technical and operational issues
    • Managing technical risk associated with new and updated technology
    • Determining measures for performance and responsiveness

    Continuum: How do we get there in the most efficient and effective manner - without damage?
    The Enterprise Architect, (fully empowered) manages the architecture and governance through operational excellence and risk mitigation
    • Structuring governance, at the enterprise level
    • Ensuring that technical solutions align with fiduciary responsibilities

  • Mark

    These are all good and you’re headed in the right direction. Another possibility is to explore and understand how enterprise architecture fits into your organization culture and you can do some mapping to determine what works and what does not. For example, given your particular EA organization maturity, map your capabilities or products and services (e.g. deliverables) to mainstream corporate processes such as strategy, performance, change, project, budget, risk, and portfolio, etc. Examine the current deliverables as compared to those that should be there. In other words, try mapping these capabilities below to your corporate processes and then add your EA deliverables to the mapping – see what happens:
    • Aligning strategic and operational views of business
    • Driving the technology vision
    • Transforming and automating operations
    • Facilitating and governing organizational change
    • Mitigating risk
    • Overseeing investments
    • Managing the architecture
    • Integrating people, processes, and technology

    You will notice the current touch points are important but more important are those touch points and deliverables that are missing. One of the keys is understanding your current capabilities, determining the most appropriate capabilities needed to support the corporate culture and of course a proficiency roadmap to transition your EA group from one stage of the journey to the next.

    Enterprise architecture enables the design and implementation of the structures that link an organization’s strategy with its execution. This vital link captures the organizational strategy as blueprints that include enough guidance and detail for the various parts of the organization to execute while facilitating collaboration and innovation. Enterprise Architects use specialized practices to determine where the company is today, scenarios for where it will be tomorrow, and they provide roadmaps that lead from one stage in the journey to the next:

    Long -Term: Where are we going?
    The Enterprise Architect (as a strategist) provides long term stability to ensure strategies are clear:
    • Creating the operating model and transformation plans
    • Developing strategic technology plan

    Near-Term: How will we make sure we stay on track?
    The Enterprise Architect (as a tactician) facilitates near-term efficiency by ensuring the operating model is flexible:
    • Increasing executive awareness of technical and operational issues
    • Managing technical risk associated with new and updated technology
    • Determining measures for performance and responsiveness

    Continuum: How do we get there in the most efficient and effective manner - without damage?
    The Enterprise Architect, (fully empowered) manages the architecture and governance through operational excellence and risk mitigation
    • Structuring governance, at the enterprise level
    • Ensuring that technical solutions align with fiduciary responsibilities

  • David Baker

    Mark,

    I can tell that you have some major experience in this area. Your insights are excellent. We (as EAs) should always remember that we operate within the context of an Enterprise Lifecycle - which you express as the “mainstream corporate processes”. That Lifecycle, simply put, is Plan, Build, and Run the enterprise.

    Here’s my mapping of EA capabilities to that simplified Lifecycle:

    PLAN
    • Aligning strategic and operational views of business (I call that Blueprinting or Strategic Planning, or Business Design)
    • Driving the technology vision (innovation, reference architectures, and standards)
    • Transforming and automating operations (I also include this in Blueprinting, etc)

    BUILD
    • Facilitating and governing organizational change (I’d also add facilitating operational changes, facilitating technology changes - EA oversight of all enterprise transformations)
    • Mitigating risk - using the EA to understand the impact of planned changes, ensuring that the implementation aligns with the business objectives
    • Overseeing investments - ensuring that the
    • Managing the architecture

    RUN
    • Integrating people, processes, and technology - a universal, across all phases
    • I would add Measurement here - EA needs to measure the business success (objectives met) and show how the architecture supports that. There should be a line of sight from the top level strategic objectives all the way through the architecture levels - operations down thru the infrastructure (see the Federal Enterprise Architecture Performance Reference Model for some excellent ideas on this topic)

    Dave

  • David Baker

    Mark,

    I can tell that you have some major experience in this area. Your insights are excellent. We (as EAs) should always remember that we operate within the context of an Enterprise Lifecycle - which you express as the “mainstream corporate processes”. That Lifecycle, simply put, is Plan, Build, and Run the enterprise.

    Here’s my mapping of EA capabilities to that simplified Lifecycle:

    PLAN
    • Aligning strategic and operational views of business (I call that Blueprinting or Strategic Planning, or Business Design)
    • Driving the technology vision (innovation, reference architectures, and standards)
    • Transforming and automating operations (I also include this in Blueprinting, etc)

    BUILD
    • Facilitating and governing organizational change (I’d also add facilitating operational changes, facilitating technology changes - EA oversight of all enterprise transformations)
    • Mitigating risk - using the EA to understand the impact of planned changes, ensuring that the implementation aligns with the business objectives
    • Overseeing investments - ensuring that the
    • Managing the architecture

    RUN
    • Integrating people, processes, and technology - a universal, across all phases
    • I would add Measurement here - EA needs to measure the business success (objectives met) and show how the architecture supports that. There should be a line of sight from the top level strategic objectives all the way through the architecture levels - operations down thru the infrastructure (see the Federal Enterprise Architecture Performance Reference Model for some excellent ideas on this topic)

    Dave

  • Andy Bolton

    The one comment I would make is in respect of Project Architecture Assistance Services in service of improving EA reputation: The dilemma of an Enterprise Architect in an organisation that has not fully committed to embracing EA as a facilitator of long term IT/business alignment* is that in playing a project assistance role the Architect will be seen as a potential barrier to achieving short term project goals. This is because they are likely to advocate patterns that have a longer term payoff (longer term cheaper, faster, reusable, more flexible, simpler etc) when most project managers and stakeholders will be focusing on their next six to nine month targets. There is also a tendency, as EAs gain traction in the organisation, working to assist projects, for them being used by a CTO/CIO as policing or consulting function for when things have already gone wrong. Either the EA has to continually make compromises (the only course of action to be seen as helping, certainly to start with) and show only incremental improvements in architecture, or be seen as a blocker of progress by advocating a longer term view.

    I would say therefore that whilst this can be a valid strategy for gaining trust (sometimes the only one) there has to be a careful strategy to move beyond project assistance to providing the future frameworks (and roadmaps) for projects via e.g. stakeholder engagement in longer term business capability enhancement.

    This is where my personal view kicks in: that the most important characteristics of an Enterprise Architect (apart from the obvious) should be in soft leadership and influencing skills so they genuinely extend their influence into the longer term architecture.

    So I agree with your suggestion, but think it must be managed carefully and with the right skills.

  • Andy Bolton

    The one comment I would make is in respect of Project Architecture Assistance Services in service of improving EA reputation: The dilemma of an Enterprise Architect in an organisation that has not fully committed to embracing EA as a facilitator of long term IT/business alignment* is that in playing a project assistance role the Architect will be seen as a potential barrier to achieving short term project goals. This is because they are likely to advocate patterns that have a longer term payoff (longer term cheaper, faster, reusable, more flexible, simpler etc) when most project managers and stakeholders will be focusing on their next six to nine month targets. There is also a tendency, as EAs gain traction in the organisation, working to assist projects, for them being used by a CTO/CIO as policing or consulting function for when things have already gone wrong. Either the EA has to continually make compromises (the only course of action to be seen as helping, certainly to start with) and show only incremental improvements in architecture, or be seen as a blocker of progress by advocating a longer term view.

    I would say therefore that whilst this can be a valid strategy for gaining trust (sometimes the only one) there has to be a careful strategy to move beyond project assistance to providing the future frameworks (and roadmaps) for projects via e.g. stakeholder engagement in longer term business capability enhancement.

    This is where my personal view kicks in: that the most important characteristics of an Enterprise Architect (apart from the obvious) should be in soft leadership and influencing skills so they genuinely extend their influence into the longer term architecture.

    So I agree with your suggestion, but think it must be managed carefully and with the right skills.

  • Pingback: 10 IT Metrics for a New CIO — CIO Dashboard()

  • Pingback: 4 Easy Ways to Kill Innovation — CIO Dashboard()