by Michael Fulton | Jul 7, 2017 | Architecture
Why is Enterprise Architecture Maturity Important?
When I talk about Enterprise Architecture, the topic includes Enterprise Architecture Maturity.
I figured it would be worth sharing a little more detail about that for additional discussion and revision. Definitely would appreciate any feedback you might have.
Before I show you the model, let me preface by saying that I am trying to provide something that makes sense to people and organizations who are just starting out in architecture as well as to people and organizations that have been doing architecture for a long time. I am not trying to capture every nuance, but instead trying to provide a simple, conceptual model for people to work from.
The entry point for most individuals and organizations into Enterprise Architecture is Solution Architecture. EA tends to start out IT-focused because that is where it has much of its historical roots, and most EA teams report to the CIO or elsewhere within IT function.
As an EA, you mature, and you expand your scope: first from a breadth of coverage perspective, then moving from proactive to reactive and finally moving outside IT and really impacting the business model of an organization.
Three Significant Steps in this Journey
First, entry into the model in the first place is key. Architecture requires a much different mindset than business analysis or application design. Understanding that mindset is the first big step.
The second major step is moving from reactive to proactive. This is critical because it provides significantly more unique value to an organization. But it also requires much more buy-in and support from senior management.
The third major step is really moving outside of IT, to directly impacting the business model of the organization. When you make this step, you must consider many more variables in the conversation. The potential impact, both positive and negative, is much higher.
There are many EA organizations that never make it to Level 3 or 4, and that’s OK. Architects can add significant value at Levels 1 and 2. The key is to know where you are on the maturity scale and to stay in your lane. When you try to run out ahead of your organizational support and buy-in, that is where you will get in trouble.
by Vish Viswanathan | May 22, 2017 | Architecture
Finding Your Next Steps
After getting TOGAF certified, what’s next on your architecture career journey? When speaking to a team of newly certified TOGAF® architects at a customer organization, most of the questions were centered around this, such as::
- How do I get started with my first EA project using TOGAF?
- How do I estimate EA projects?
- How do I create an EA Repository?
- How essential are modeling skills?
As the questions kept coming in, it was clear that we weren’t yet differentiating between the three big buckets of work outlined in TOGAF, that is:
- Creating an architecture practice
- Running an architecture project
- Governing the enterprise’s architecture
The certification process provides one with a good conceptual knowledge of TOGAF and EA, but doesn’t really clarify these three big buckets or talk about how to put your new knowledge about each of them into practice.
Here are a few tips on the most important of the three big buckets to a new architect:
Three Things to Remember
First, learn when to start and when to end the EA project. You are covering phases A through F of the TOGAF ADM. You are not overlapping with the actual design and development of the software!
Second, the time you spend and the quality of work you do in the ‘A’ phase of the ADM will decide the overall success of the project. Here are some things to consider:
- A discovery workshop can bring clarity in terms of the issues, goals, gaps and scope. Bring your business and IT teams together on the same page and watch them argue and differ on challenges, gaps and issues.
- Developing an EA value proposition for the specific project is one of first things to do to communicate value to your stakeholders. It will also help keep you focused on always delivering business outcomes.
- Develop and demo a few sample EA artifacts using an EA tool. Try these out with friendly stakeholders to see how they resonate. Be sure to reuse templates from others in the organization that have worked before.
Third, remember, you are running an architecture PROJECT. Treat it as a project, just like any good PM would do.
- Create EA project estimates based on how many business units are participating, roughly how many business processes you are addressing and their complexity. To get the hang of it, dig into process documentation, application code and workflows, and database tables. Interview stakeholders. Be ready for site visits such as call centers, data centers, corporate offices, warehouses, and so on.
- Develop an EA roadmap that clearly highlights milestones and deliverables in a way that anyone can understand.
- Business process modelling is best approached from the organization chart. For each business unit, model high level processes and then drill down to the next levels. Develop your own hierarchy of business services -> business processes -> business sub-processes -> application functions, etc. Then you can rationalize back up into business capabilities. Trying to work from business capability first rather than org structure is actually much harder for your customers and stakeholders to understand up front.
- Demand the right kind of people: Since EA is a horizontal function, it draws resources (architects) from the line of business or business units for the duration of the EA project.
- Use the right tools: Many EA tools have good TOGAF plug-ins that can guide you through the ADM phases. Use one if you can.
- Be flexible: There is no need to strictly adhere to a TOGAF way of doing things. As long as you follow the general philosophy and the ADM flow, that should be enough.
Earn Respect with Consistency
Remember, every customer use case is unique, but the TOGAF approach is more or less the same. As long as you can show incremental value to your stakeholders by creating artifacts to convey direction or highlight process gaps or drive organizational reuse, you are definitely in the game.
