Geeks With Blogs
A Technical Debtor Toward continuous improvement

Let me preface this by saying that I couldn’t keep up with Dave, and he has much more to say than I could capture here. He’s quite willing to discuss this more. Feel free to contact me for his contact info

Problem statement: architecture is challenged by a perception that design and development standards are too abstract or irrelevant. This is exacerbated by the misperception that agile processes eliminate the need for good design and architecture practices. So, how do we build enterprise-class solutions and assure the adoption and use by software and EDW/BI teams?

Gartner gives good guidance for CIOs in creating an EA plan. However, the framework itself is an implementation choice, be it TOGAF or Zachman (ZIFA).

“Nothing is particularly hard if you divide it into small jobs.” Henry Ford

There’s lots of reasons that we have problems with this:

  • we get less time than we need
  • our business world and rules are complex
  • stuff happens
  • we have lots of processes and standards… but they don’t tell us how to ensure value
  • general mandate to create business value

Concentrate on reducing friction and improving speed. All the pieces must work efficiently together… or value is lost.

How do we get there? Some lean concepts:

  1. simplify your business model
  2. modularize the blocks
  3. standardize the interfaces
  4. look at the points of rapid change
  5. know the overall economics and throughput
  6. focus on the constraints on value throughput
  7. manage to the vital signs (3-5 KPIs)

What do we need to know? Strategic goals, operational goals and operational capabilities. Our intuition is valid – there is a complex neurological engine that solves complex problems. However, we need to formalize this intuition; otherwise, we end up with assumptions that cause problems.

How do we get there? Business capabilities, technical capabilities, organizational capabilities, integration capabilities.


  1. define dimensions and service level expectations
  2. use top-down thinking in combination with bottoms-up
  3. adapt use case outline to manage user story inventories
    • connect User Stories together in context with the business value
    • carve up the problem into bite-sized pieces
  4. map business architecture to solution design architecture components

What are the dimensions of alignment?

  • Business processes
  • Domains
  • Environments

Managing User Story Inventories for Completeness

  • helps ensure that we cover the basic requirements (precedence, end states, exceptions, business rules, UI specifications, domain, environment)  for each user story
  • spreadsheet-style tools, like Rally, can help

The structure of an organization is slower-moving than the requirements or the capabilities. The architecture shouldn’t need to change unless the company change what they’re doing (or unless a technology shift occurs).

Michael Porter (“Competitive Advantage,” 1985) suggested that there are 5 primary activities we do as a business (inbound logistics, operations, outbound logistics, market/sell, service) to create value. Secondary activities (procurement, HR, technological development, infrastructure) support the creation of value. Projects that don’t clearly affect the value chain are questionable.

Remember: Strategic Goal => Operational Goals => Operational Capabilities

Once we know what we need to do, we can design the business architecture and the technical architecture. The business architecture should be a logical arrangement of tasks or capabilities, but does not dictate organizational structure or roles. Note that it is the business processes, not the tasks, that provide business value.

Posted on Monday, April 20, 2009 7:41 PM | Back to top

Comments on this post: IASA Denver – Making Architecture Business-Value Driven (Dave Guevara)

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Jeff Certain | Powered by: