Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.
This is the one but last posting of the enterprise architecture Roadmap for success blog series, before we wrap up. In the last three postings of the series we touch on some aspects pertinent to the execution phase of the winding path that is enterprise architecture implementation, as depicted below.
Roadmap for success: Governing projects
Good architecture governance is a key success factor for an enterprise architecture function to deliver real value to the organization. Creating enterprise architecture is one thing: Using the right tools and techniques, enterprise architects can come up with the most brilliant plans and road maps that would definitely give the organization a valuable edge. But if no means are available to guide and control the adoption of the plan, the plan is still worth no more than the paper it is written on.
That is exactly where architecture governance comes in, but it does not exist in isolation. Architecture governance should tie into a broader framework that on the highest level is often referred to as corporate governance. Many definitions of governance are around. Wikipedia describes governance in a business context as consistent management, cohesive policies, guidance, processes and decision rights for a given area of responsibility. TOGAF™ defines architecture governance as the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level.
Corporate governance, the broader framework
To bring back in mind, enterprise architecture is about answering the question (over and over again): “how should we organize ourselves”. The output is usually defined in terms of changes to the way we are organized at this very moment. Those changes are necessary to respond effectively to opportunities that somehow emerged or came along in the environment of the organization. In most organizations the vehicles of change are projects, and organizations often operate a project management function that is tasked with the definition and execution of projects. So for many organizations, in order to absorb and use the value of architecture, project governance is an obvious and typical starting point.
Proactive vs. Reactive
Project governance in itself is a conceptual ‘thing’. How it is actually implemented in an organization varies, depending on many factors. Usually there is a governing body; in more formal and mature organizations this is often the Architecture Board (as described in more detail in posting four of this roadmap for success series). In other organizations we see that project governance from an architecture perspective is part of the project management process, and that there are some architectural requirements (e.g. a checklist) defined for projects, that have to be met before they can advance to a next project phase. The latter approach can work pretty effective, but the risk is that if architecture requirements are presented to project managers as a checklist, that it is perceived as just another hoop to jump through.
In that case, a more proactive approach is needed in order to help projects benefit from architectural output. An example is to set up projects in their earliest phases with project start architectures. These are documents derived from the enterprise architecture but narrowed down to the subject area and context of a specific project. It describes in terms of models and principles how the results of a project fit into the overall architecture, and how to optimize the results in terms of value for the business.
Also projects should be in a very early stage aware of what standards are that can be leveraged for the benefit of the project. Enterprise architecture should manage and communicate architecture standards in such way that they have ample visibility and accessibility for projects, and that they are documented in such way that they give clear guidance on how to use standards. Earlier we posted a complete blog series on architecture standards; see those postings for more details around managing architecture standards.
Some managers see architectural requirements as checklists. edunderwood.com/tag/legalism/ 1
In this posting we have made the case for good governance in order to maximize the value of enterprise architecture. In our opinion, the governance framework that the organization want to use to manage and control enterprise architecture should be well worked out and formally implemented on the one hand side, but should be pragmatic and flexible enough in order to remain practical as well. Project governance is a good starting point, and should be focused on helping projects to use valuable knowledge from the architecture function for the benefit of project results. Examples are project start architectures and architecture standards.
If you’d like to know more, please contact the authors directly at email@example.com / firstname.lastname@example.org, or leave a comment. The next post in this series is about governing projects. It is scheduled to be posted between 22 and 26 april.
SUBSCRIBE TO BIZZDESIGN'S BLOG
Join 10.000+ others! Get BiZZdesign's latest articles straight to your inbox. Enter your email address below: