In this installment of StraightTalk, we are further exploring a big, scary and loaded concept of business architecture governance. In Post No. 38, we took a practical look at what we should govern. In this post, we will look at how to implement the governance concepts we discussed previously. Here goes again.
P.S. Post No. 38 is a prerequisite for this post to make sense, so you may want to read or brush up on that one first.
How do we approach business architecture governance?
Keeping in mind that introducing business architecture to an organization is really part of a bigger change (e.g. a new vision for strategy execution and working together as an enterprise) and also the lessons we can learn from other architecture governance implementations, we need to approach business architecture governance practically. Here are some key guidelines:
- Introduce business architecture governance just in time – Step into the various aspects of governance as you reach key business architecture milestones, and it becomes relevant (see diagram later on in this post). What does not work well is establishing governance because it’s a step in a methodology or because it seems that other organizations are doing it.
- Govern what is essential – Focus your precious time on what is most important. For example, focus on governing target architectures and strategic roadmaps versus every detailed deliverable. Or, focus your business architecture service delivery governance on outcomes, not whether each step was exactly followed as prescribed.
- Keep governance processes light and potentially informal until the organization matures – Increase the rigor of your governance with your business architecture maturity. Especially in the beginning, lighter governance will encourage more people to participate as well as allow for learning and evolution.
So, where do we start to implement business architecture governance?
As an organization’s business architecture practice matures, there is a logical progression of when to implement each aspect of business architecture governance, depending on when the actual thing being governed is put into place. Of course, the journey to maturity is not the same for every organization, but there is a commonality of how they progress through business architecture milestones. (P.S. Check out Post No. 4 on the business architecture practice maturity journey.)
As a result, here is an approach to introducing the various aspects of business architecture governance over time, simply stated:
- Introduce knowledgebase governance to manage changes to the business architecture baseline (a.k.a. capabilities, value streams and the cross-mapping between the two, as described in Post No. 22) just as soon as you have published your first version 1.0.
- Introduce practice direction governance after you have formalized your practice and defined your charter (with purpose, value proposition and measures of success) and have begun applying business architecture in enough instances where you can assess the outcomes.
- Introduce business architecture service delivery governance after you have formalized the services you will deliver and your methodology for delivering them and have begun delivering these business architecture services in enough instances where you can assess the outcomes.
- Introduce business architecture tool governance after you have implemented an automated business architecture knowledgebase tool(s) and defined how it should be used within your methodology and enough practitioners have begun using it.
- Introduce target business architecture governance the first time you use business architecture to drive your first large change initiative, such as an enterprise-wide transformation.
- Introduce business architecture as an enabler into other governance processes at various points across the strategy execution life cycle (e.g. to compare initiative results delivered to original business objectives, using business architecture traceability) as the discipline becomes embedded over time.
This is illustrated in the handy diagram below.
Who does all of this business architecture governance?
This varies based on an organization’s situation and dynamics, so simply stated:
- Any architectural reviews related to content are performed by people on the business architecture team (which could be anything ranging from the top architect to an architecture board).
- Any business reviews related to content are performed by the business people, and typically at multiple levels within the organization, though the final approval usually comes from an executive (which could be anything ranging from an individual executive to a committee).
- Any practice reviews are performed by people on the business architecture team, though they may also involve others outside of the team (which could include a steering or advisory committee comprised of others with business or technology perspectives).
What about capability ownership? Aren’t we supposed to have that?
Depending on how you interpret capability ownership, this is typically referring to the business involvement in business architecture knowledgebase governance and/or target business architecture governance. (See diagram below for context. You can check out the full story in Post No. 38).
As mentioned earlier, resist the urge to implement this type of governance too soon, especially before the business architecture and its usage are fully understood. Otherwise, you could run the risk of reinforcing your current silos (or creating new ones) and implementing governance for the sake of governance.
Here are a few key considerations when implementing capability ownership:
- Implement capability ownership only after your capability map is reliable – and that means you’ve not only created it but have been using it for a while to test it
- Have a clear purpose for what you want to achieve with capability ownership
- Consider that ownership might be more relevant to a set of capabilities (e.g. all customer-facing capabilities) versus splitting ownership by level 1 capabilities*
- Consider that ownership might involve more than one person (e.g. a committee of business leaders that govern the customer-facing capabilities)*
- Consider the value stream perspective – this does not imply that you must have value stream owners as well, but the perspective should always be considered when making capability-related decisions
* For these reasons, capability ownership is typically best approached as target business architecture governance, introduced when the organization is at a higher level of maturity.
What are the elements to consider for each aspect of business architecture governance?
For each aspect of business architecture governance, consider the following:
1. Structure
- Who makes decisions?
- What organizational structures will be defined (e.g. governance committees, roles)?
2. Process
- What are the processes for review and approval?
- When will the processes occur?
- What is the scope of review?
- What review criteria will be used?
3. Measurement
- How will the results be measured? (Throwback to Post No. 21 where we discussed different measures of business architecture value and maturity. The results of your governance process can become some metrics that you may choose to track over time.)
4. Communication
- To whom will the results be created and for what purpose?
- How will the results be communicated?
Closing Thoughts: Remember that business architecture governance is not an isolated, theoretical activity. It is about something much bigger: the organization itself. An organization’s business architecture represents the very design of the organization and target business architectures also reflect how the organization will change as a result of the strategic business direction. So, business architecture governance is actually a means of ensuring a solid design for an organization as well as its future evolution.
More Good Stuff
Tying Business Architecture to Business Strategy (State Farm at Business Architecture Guild® Summit): Learn from your friends. Here is an example of using business architecture through strategy execution to shift to an aspirational state (including the use of target architectures and strategic roadmaps which would be governed).
A Powerful Pledge That Spreads Accountability in the Workplace (TED Talk): A TED Talk by Garry Ridge, CEO of the WD-40 Company, who shares their pledge for personal accountability and the remarkable impact it has had on their bottom-line.