It isn’t true for every EA practice, but I’m willing to bet that for most EA teams the start of a New Year includes a review of what’s happening and how that might change!For some companies the New Year coincides with the start of their planning year, and there are still many companies that seem to go through an annual reorganization of the management structure charts.
In any case, New Year is a good time to take stock and think about the future – so here are my recommendations for using TOGAF as your guide.Taking stock is partly about checking that you are on the right track and making sure that you have everything you need in place to be able to complete your plans.
This is covered by the objectives of the Preliminary Phase of ADM – to determine and establish the Architecture Capability desired by the organization. So it is well worth revisiting this Phase to review each aspect of the enterprise architecture that is covered there.
As a Simple Example…
An EA team reviewed the scope of the Enterprise: during the previous year their company had completed several acquisitions, but no one had ever explicitly said that the enterprise scope should be extended to cover the new business areas. It is also worth looking for any new opportunities for architecture work – perhaps by looking at what has been happening through other management frameworks in business planning, operations management or portfolio, program and project management.
When you review requirements and change programs across the enterprise it is a good time to revisit stakeholder management. If you already have a list of stakeholders, go over the list and check how each stakeholder is impacted by EA projects.
You should also start with requirements and change programs to make sure that your list of stakeholders is current.
TOGAF recommends that you classify stakeholder positions and then determine your approach for each stakeholder. At the New Year, resolve to create any work products or artifacts that you need to address every stakeholder view and viewpoint!
Which Takes me to my Next Suggestion…
A good EA team will try to make the best use of their deliverables and work products. It is so easy to produce “single use” documentation – things that are produced for a particular project and then never referred to or used again.
With a little adjustment, most outputs can be reused, at least in part.In TOGAF, Part IV of the documentation covers the Architecture Content Framework, and it’s useful to have a practical content framework that you’ve tailored to your specific needs to help you get the best out of your deliverables.
I would recommend that you check the list of TOGAF artifacts and deliverables [Chapters 34 and 36], but adapt these to make sure you meet all of your stakeholder concerns. You should also use relationships in the Metamodel to see where you can leverage information about one part of the architecture against information about another component.
For example, checking business services against events might highlight processes that are prime candidates for architectural improvements.
Capabilities and Skills
Another topic to review are capabilities and skills. It is useful to go over previous maturity assessments to check that there has been some improvement! Maturity models can be applied to the EA team, the enterprise architecture, or business capability, and in each case a maturity assessment can help to highlight where there are problems, where there are opportunities for improvement, and how to improve effectiveness.
The Architecture Skills Framework [Chapter 52] has some useful checklists to reassess roles, skills and depth of knowledge. Again, you should always adapt the material that TOGAF provide to meet your needs.
For example, one EA team added 17 new skills to the list of Enterprise Architecture Skills, including things like Classification, Problem Domain Analysis, and Storytelling.
By adding these additional skills they had a more comprehensive checklist to enable them to train individuals and develop their team capability.
Revisit the Enterprise Continuum
Finally it is useful to revisit the Enterprise Continuum. The Enterprise Continuum isn’t only a way to classify architecture and solution artifacts. It is also an effective way to manage them. It is a technique for adapting new material from external sources that can be tailored for use in an enterprise-specific context.
There is always new material being developed – new reference models, new standards, or new concepts and ideas. The New Year is a good time to see if any of these developments can help you. But you can also apply the ideas behind the Enterprise Continuum to manage artifacts within the enterprise.Remember that it is a continuum – there are no fixed points, and you can create additional reference spots along the continuum as you need them.
EA teams frequently add to the continuum within the enterprise-specific zone. For example, artifacts that are created for a business division or project can usually be generalized for future re-use – creating enterprise-wide artifacts that form a template that can be reused in many contexts. What has your team created in the previous year that could be generalized in this way?
And Finally…
I started out by saying that a New Year is a good time to review what’s happening and how that might change. And so it is. But of course, the ideas that I’ve listed here could be applied at any time.
The key points are that EA happens in a context that is continual flux – there will always be new requirements, emerging concerns, stakeholder changes, and innovative ideas. And the best way to keep up-to-date is to schedule time to reflect and adapt to this ebb and flow.
