This is a Flickr badge showing public photos and videos from Chief Architect. Make your own badge here.

Search ...

Powered by Squarespace
« Leo de Sousa | Main | Effective architecture diagrams »

Enterprise architecture is nothing without delivery

I have written on this subject before, this time I will be specific about what we architects must do to achieve delivery. The issue that prevents good architecture being delivered is created entirely by our failing to understand our own job.

Architecture is about doing the right things right.

In general, we understand that we support strategic, project and program decision making to help the organization understand what the right things to do. We understand that we must perform a technical guidance and governance role to ensure that the right things are done in the right way.


We often fail to understand the scope and scale of these activities. They are not minor side activities; they are not things to be done in spare time. Once we have any sort of architectural direction, they must be the main focus of our activity and the main usage of resource. Let's be clear, if we are spending more than 50% of architecture time is spent on creation of architectural artifacts then we have it wrong.

What should we be doing? We need to focus on the “lines”. How do we use our architectural artifacts and our knowledge to support our immediate customers i.e. the strategic, program and project management, and the delivery teams.

First, the organization or the program or the project must spend money on doing what is right. It is the management and governance structure that makes these decisions. These decisions take place at a number of levels:

Strategy – what business are we in? What are our core competencies? How do we structure ourselves? What products and services do we offer? Who are customers? How do we interact with customers and partners? This is where business architecture is critical.

IT governance – what is the IT strategy? What is the sourcing strategy? What is the project and program portfolio? What application and service portfolio is required? How much can IT spend on delivery? What services levels are required? Enterprise wide IT architecture and business architecture drive these decisions. Service delivery escalations.

Program and Portfolio Management – what is the correct scope for a project? What are the major milestones? What are the relationships between projects? What is the correct management structure? Project and program escalations.

Business Change Planning – What pace of change can the business achieve? Is business and IT change fully aligned? Is there effective communication between the business and IT to ensure change remains aligned?

Application and Infrastructure Landscape Management – Is the IT landscape changing to meet business needs? What constraints does the IT landscape impose on the business? What business risk does the business dependency on IT create?

Information and Data Governance – Are master data management business processes effective? What impact does poor master data have on the business? Is data quality managed effectively? What information do people need to do their jobs effectively? What value does business intelligence add to the business?

Carrying out these activities effectively depends on having architectural artifacts in place. However, the value of the artifacts is in the communication and analysis of them in order to answer business questions.

Once the organization decides to do the right thing, it needs to deliver it and deliver it right:


Program Delivery Support – What are the business and IT dependencies? What are the business and IT risks? What are the correct mitigations? What are correct delivery lifecycles for each workstream? How can the timelines for each workstream be aligned? What risks and issues should be escalated?

Business Release and Change Management – an IT release will require a stream of business change activities that will need to be synchronized with the IT capability that is delivered. Any change from the business or IT side will require an impact analysis and a re-synchronization.

Design Support – business and IT delivery teams must understand what, when, how, why, and where to use apply different tools, techniques, patterns, standards, processes, etc. Support must be easily accessible, timely, friendly and impose a minimal overhead.

Delivery Process Oversight – delivery effectiveness and efficiency are bound up with delivery excellence at the detail level. When the crunch comes, project timelines and costs will often take precedence over architecture. Effective architects ensure that good delivery processes (e.g. estimating, configuration management, release management, resourcing) are in place and followed. This reduces the possibility of time and cost pressures causing architecture to be compromised. For this to be effective, this role must be carried out sensitively.

Service Delivery Oversight – architecture is delivered through production processes and systems. It always amazes me how few architects get out to the sharp end of delivery and experience reality. Architects need to be closely involved in escalations, major incidents, key risk and issue management, critical dependency and assumption management, and change control. This ensures that architects remain grounded and they have an influence on the real world fixes that potentially will compromise the architecture.

Business and Technical Design Authority – as David Linthicum says “you must have some kind of hammer to drop on somebody's head”. Ideally, you should never have to use it. By successfully executing the supportive approaches above, the design authority role is a confirmation that architecture has been applied correctly or deviated from appropriately. There will of course be some unplanned deviations.


For enterprise architecture to be a success then it is critical that the main emphasis is on the collaborative activities that apply the core architecture artefacts to business and IT delivery. This allows value to be demonstrated, it leverages the expertise of the architects into business change and business operations. Perhaps more importantly, it leverages the expertise of those in the business and IT who are at the sharp end to ensure that enterprise architecture is relevant, useful and actioned.

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (2)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (1)

Interesting article. By asking questions in these categories, you make it clear what kinds of decisions EA supports.

In a separate post, I tied together high level EA activities in a process flow. I'd like your feedback.

Would you do me the honor of looking over the process flow that I posted? I'd like to know if you agree that I captured the necessary flow to enable these activities in the business functions described.

June 14, 2008 | Unregistered CommenterNick Malik

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>