The Architecture Value Proposition

A lot of discussions are flying around on the Enterprise Architecture boards about our role (or lack of) and the need to demonstrate value. Some have even questioned why this is so (after all, we all know the value of accountants, right?).  Do all EA professionals have an identity crisis?  Seems so, and I decided to share this post to clear the air a bit and share some thoughts of the kind of value we should deliver to our business peers.  If you are impatient enough with this introduction just scroll down to the “money” section and see what a quick taxonomy (not complete by any measure) of what our value proposition should look like – at a minimum what values we should find in our day to day work to share with our business peers on a regular basis. If this sounds like a lot of foo-foo to you, get ready to be challenged on a regular basis – and spend an inordinate amount of time and effort justifying your pay-check.  And less time solving for the important and urgent challenges we have been asked to help with.

First, how about a little context?  I believe (and I think you will too) that architecture is a comprehensive framework of well understood processes used to manage and align an organization’s IS assets with:

  • People and Organization (Structure)
  • Processes, and
  • Technology used to meet specific, actionable strategic business goals.

For example, reference the Galbraith Star Model.
A typical design sequence (in my world) starts with an understanding of the strategy as defined by the business. This in turns drives the organizational structure. Processes are based on the organization’s structure. Structure and Processes define the implementation of reward systems and people policy.

This is one way to understand our true role in architecture management is to ensure technology investment and widespread adoption within the organization occurs because:

  • The investment has value,
  • The program (projects) will be properly managed,
  • The organization has the capability to deliver the benefits,
  • Dedicated resources are working on the highest value opportunities,
  • Projects with inter-dependencies are undertaken in the optimum sequence.

Actionable objectives this function (architecture) enables include:

  • Driving costs (not shifting them) from the business processes meta-cycles and improve value-added efficiency across operating models
    • Cycle time reduction
    • Error reduction
    • Resource liberation
    • Cost reduction
    • Cost avoidance
  • Turning service portfolio investment into an operational variable cost which can relate directly to business volume
    • The business should only pay for what they use…
    • Can budget for services on a per usage basis
    • Use Strategic decision-making framework to:
      • manage cascading goals to evaluate corporate or shared goals along a vertical and horizontal axis to mitigate alignment issues
      • use functional views to focus IS investment choices
    • Realizing economic value through business process improvement as a:
      • Vehicle to drive measurable performance improvement:
        • Reduces defects embedded at the design stage of lifecycle by applying architectural principals
        • Uses problem solving approach upstream, reducing operational rework costs.
    • Enable process optimization through continuous, complimentary investment in reengineering and organizational development.

Our work then is to develop and promote management’s use of architecture to drive costs out of the organization and continue to meet stakeholder demands for distinctive, quality products and services.  The value proposition we bring should include detailed findings and quantitative methods to uncover how to accomplish this to meet the following objectives:

  • Improved planning helps to make more informed decisions. Ensures project plans are complete and consistent with business priorities and addresses the impact of changes (alignment) as needed.
  • Technology investments can be managed using consistent, repeatable processes to effectively build (acquire), maintain, and retire these assets over their useful life.
  • We can enable cost efficiencies through elimination or consolidation of redundant or obsolete resources.
  • Delivering quality information, designed and architected for the enterprise as a whole, has proven time and time again to be faster and less expensive by:
    • Reducing complexity
    • Encouraging component reuse
    • Improving communications within the organization
    • Providing a standardized, easy-to-use reference models and templates.
  • We can significantly improve IT and business alignment by encouraging the rapid adoption of technology to meet changing business needs in an effective manner. Improved service levels to key constituents — customers, employees, partners.
  • Encourage less expensive development and delivery by reusing and leveraging previously-developed shared services and products. Results in lower maintenance and integration costs. Provide a logical construction blueprint for defining and controlling the integration of systems and components by combining organizational, data, and business processes.
  • Communicate using common terminology, standard descriptions, and generally accepted industry standards between the business and technology providers.

Delivering Value

The following section represents the majority of the business value I have helped other organizations uncover and exploit through the architecture function. We should be able to quickly discover and describe each of the opportunities we encounter within technology management alone (forget about the business for now) to include:

  • Plan to Manage (Lifecycle),
  • Manage to Availability (Protect),
  • Request to Resolve (Support), and
  • Develop to Deploy (Develop).

We should be able to tie service orientation for example, to its impact on one or more target metrics – use short-term tactical focus to start with and describe its impact (i.e., quantify its value, examples are included) in terms of:

  • Process Cycle Efficiency (reduce the time to close a defect by 40% within three months)
  • Time (Reduce system testing time by three weeks on the next project)
  • Accuracy (Improve schedule estimation accuracy to within 10% of actual)
  • Resources (Reduce maintenance costs by 50% within one year)
    • People
    • Money
    • Physical (e.g., physical plant, infrastructure)

The following themes represent the significant elements we should examine and evaluate for the size and relative scale of the respective opportunity that can be realized.


  • Communicate effective alignment of IS strategy
    • Clear understanding of the current and future direction
    • Ensure business focus is on the highest priority and mission critical efforts.
    • Make more informed decisions
      • Control Strategic Scope and economic intent
      • Enhance investment decision-making by providing ready access to the business to information about the people, processes, and technology.
      • Assess the impact and mitigate risks associated with tactical decisions.
  • Improve Service levels
  • Produce Higher Quality Products
    • Improved reliability
    • Predictability (variance reduction). Methods to deliver services and information in a consistent and structured manner.
  • Increase project success rates
  • Meet operational goals and objectives
    • Process control objectives
    • Professional staff is accountable for compliance with policy and management direction.
    • Optimize activity objectives


  • Shorten work cycles
    • Improve Process Cycle Efficiency
      • Shift focus to value-added activities
      • Minimize Non-Value-Added activity
      • Eliminate obsolete non-value added practices
      • Optimize Essential Non-Value-Added-But-Necessary activity
    • Schedules
    • Maintenance costs
    • Development time
  • Reduce costly rework
  • Leverage Economies of Scale – Consolidation
    • Leverage existing IS assets
    • Shared knowledge base
    • Infrastructure and Shared Services
    • Skills and resources
  • Reduce or eliminate redundant investment
  • Promote Interoperability
    • Identify opportunities for vertical and horizontal interoperability between business units.  Improve or reuse existing IS assets.
  • Improve developer productivity
    • Leverage strengths of different types of developers.
    • Preserves business logic by isolating significant changes to “plumbing”
  • Reduce Need for Customization
    • Lower labor costs and lower Total Cost of Ownership
  • Enable vendor independence
  • Leverage the benefits of Standardization
    • Use standard, reusable components and services
      • Proven – Based on field experience
      • Authoritative – Offer the best advice available
      • Accurate – Technically validated and tested
      • Actionable – Provide the steps to success
      • Relevant – Address real-world problems
    • Use common processes, methods and tools
      • Tooling
      • Wizards
      • Templates
      • Metadata, Code configuration generation


  • Adapt quickly to changing business needs that require significant requirement changes
  • Accommodate Emerging Technologies
  • Engineering Life Cycle Support
    • Streamlined Governance and Stewardship
      • Meet Process control objectives
      • Optimize activity objectives
    • Guidance for tasks such as deployment and operations
  • Prepare for New Opportunities
    • Off-shoring
    • Emerging technologies
  • Improved Speed to Market
    • Increased productivity due to the need to develop and test only code that is related to business requirements.
  • Higher levels of customer satisfaction
  • Improve communications
  • Illustrate and communicate the business of the enterprise to all stakeholders
  • Common terminology and semantics
    • Standard descriptions
    • Generally accepted industry standards and models
    • Promote Global collaboration
  • Improve Risk Mitigation Strategies
    • Leverage proven Business Reference Models
    • Identify Capacity Planning needs and impact
    • Reuse previously identified Solution Set patterns that link preferred Business, Information, and Technology Architecture Components.
    • Provide explicit linkage between stated business goals and the solution proposal (clear line-of-sight).
  • Support Innovation
  • Identify opportunities to employ innovative processes and technology.


  • Drive one or more systems to common “use” or purpose
    • Shared information is more accurate. Information is collected once and used many times, avoiding the misunderstandings and keying errors associated with multiple collection points.
    • Shared information is more timely. Information can be made available instantly rather than waiting for a separate collection effort.
    • Shared information is more complete. Information from multiple sources can be assembled into a full description.
    • Shared information is less expensive. Information costs much less to store data and send it to another user than it does to collect it again.
  • Work Product Impact
    • Less variance in work products
      • Provide atomic solutions to recurring problems (Solve problems once)
      • Application Frameworks standardize the way in which a class of problems is solved.
      • Set of classes which enforce the architecture
    • Teach developers how to use it
    • Support and evolve framework

This is how I have demonstrated real business value in my practice. Not sure why this is still questioned unless our role remains a mystery (poor communications) or maybe we have simply not executed (execution failure does happen).  So hopefully this has helped some of you to understand and place into “business terms” the kind of value we should be delivering to our business peers.  And more important to all of us in the profession is how we can define an effective value proposition to share benefits that can be realized in a sustained, consistent, and repeatable manner.  Thanks for listening…


The Business Case for Enterprise Architecture

We have the frameworks. Plenty of them: Zachman, IEEE STD 610.12, FEAF (Federal Enterprise Architecture), and now an updated TOGAF (Open Group Architecture Framework) you can find more about at (

We know what to do. All of us know what should be done and have a pretty good idea of how to do it. For example see what the GAO has institutionalized in their view of our profession in the publication labeled “A Practical Guide to CIO Council – Federal Enterprise Architecture. February 2001, Version 1.0 “.

Why do it?
Now comes the hard part. How about a business case for investing in this discipline? Expressed in terms ordinary business people can understand.  I have yet to find (I have looked) a really compelling piece of work that can express quickly what impact EA would have across five essential elements every business leader understands and manages to on a daily basis:

– cash flow
– margin (profitability)
– velocity
– growth
– customer (responsiveness, intimacy, and alignment)

I’m  guessing this is because we are all technicians at heart. I have also come to believe this is essential to having our peers in the business understand our value proposition. I remain convinced this discipline can (done properly) enable significant improvements in each of our organizations.  Any thoughts or suggestions are welcome, encourage all of us in this profession to evaluate and think carefully about what our real value is – as business people first, then as trusted advisors and partners to our business and IT colleagues alike.

Where is Architecture when we really need it?

Times are tough. So tough, many are slashing important spending in Enterprise Architecture. For example, treating IT as a cost center managed in a cost-containment mode means for most they will overlook the truly significant opportunities to improve profitability, leadership, and ultimately brand share that may not come around again. Depending on who you believe, the average company IT spend is anywhere from 5% – 12% (financial services) percent of operating expense or 95% to 87% percent of operating expense that isn’t in IT. I think Howard Rubin’s organization (the benchmark guys) have found organization’s that treat IT spend as an investment and true enabler rather than cost is probably worth anywhere from 2 to 5 percentage points in gross profit depending on the nature and intensity of IT in the business. Furthermore, I remember reading Empirimetric’s analysis during the last recession of 3,000 business units from more than 300 corporations found that operating effectiveness contributes to a company’s financial performance just slightly more than pure dumb luck and random events. A fresh perspective? Maybe; In fact if memory serves me the study revealed that profitability is directly and indirectly influenced by:

– Strategic moves initiated by the business: 10%
– Luck and random events: 10%
– Operating Expense Reductions: 15%
– Market Awareness, Competitive position, Customer Intimacy: 65%

So without sounding a little self-serving, you have to wonder what most of the leadership across industries (and the VC community as well – industry has no monopoly on being clueless) is thinking. Has the “paradox of thrift” or the hollow promises of “financial engineering” permeated everyone’s thinking? What can we do as pragmatic enterprise architects to help?  And reinforce our true value proposition when the financial engineers begin slashing and burning?  Maybe a good place to start is to begin thinking in business terms about some very real challenges our peers are addressing right now. For example, others have demonstrated:

– Up to 50% of existing customer relationships are not profitable.
– A 5% increase in retention can increase profits 60-100%.
– It costs 7-10 times as much to acquire a new customer as it does to retain existing customers.
– Long-term customers buy more, take less of a company’s time, and are less sensitive to price.
– Fortune 500 companies typically turn over (lose) over 50% of their customers every 5 years
– The average company communicates 4 times per year with its customers and 6 times per year with its prospects (you have to love this one <g>).

As architects we can add real value to solve for these issues by gaining an acute understanding of what it takes to enable actionable results – beginning with key organizing principals (framework) to guide decisions from funding to widespread adoption. For example,

– We can identify unprofitable customers, products, segments through robust analytics
– Improve delivery capacity (utilization, planned vs. unplanned) by enabling a more effective understanding of the portfolio of goods and services as delivered across organization boundaries
– Help the business adopt Time Driven Activity Based Costing to quickly gather and model findings
– Enable operating model optimization – shift to more value-added work. Use analytics or MDM to identify opportunities to automate or replace low value-added essential activity (e.g.; hunting and gathering data points, duplicate validation and verification of data values) and measure progress to plan as action is taken.
– Improve Process cycle velocity. Identify unnecessary latency, waste, rework in work streams and reengineer or eliminate altogether. 

These are a few examples where the applied architecture makes sense; business sense.  For those of us in architecture management we have a responsibility in our role is to ensure technology investment and widespread adoption within the organization occurs because:

– The investment has value,
– The program (projects) will be properly managed,
– The organization has the capability to deliver the benefits,
– Dedicated resources are working on the highest value opportunities,
– Projects with inter-dependencies are undertaken in the optimum sequence.

Will explore some real world examples in the coming weeks, and welcome your thoughts and comments on this important and urgent need.