Enterprise Architecture has earned enough awareness and strength these days that it has become a strategic and most critical part of any major business or technology transformation and modernization programs. However, there are still questions and confusion about an Enterprise Architecture program, its practice at an organization and the organization structure, how to start enterprise architecture and where does it fits in overall business strategy and how it will all play out. These questions if not answered early can lead into failures and potentially disasters and train wrecks. You will then need to spend more money and time to fix the program than its execution. This article put some brief idea of how to start an enterprise architecture program and how to practice enterprise architecture at your organization.
In my experience, I have seen that an Enterprise Architecture initiative started as a result of (a) hiring of a new business or technology leadership (b) business transformation resulted from M&A (c) major cost cutting initiative to increase shareholder value (d) external government or regulatory mandates. In all of the above, scenarios (a) was more common. Probably, it may have been just a poster child of scenario (d), after organization decides to change their operating and reporting model following regulatory guidelines mandates.
One of the differences between an enterprise architecture programs versus an enterprise architecture practice is that, an enterprise architecture program runs to achieve a short-term goal, as oppose to an enterprise architecture practice, which is responsible for its ongoing operation, maintainable, monitoring and improving the performance. Enterprise Architecture program typically or ideally runs 18-24 months for a medium sized business and it could go beyond 36 months for large scale corporations. As most of us have seen, it is said that an average turn over time for a CIO is about 3 years. And within the first 18-24 months the new CIO should (must) be making an impact for his or her long term career success. So I would think that these leadership changes are associated with big impact business transformation programs and an urge to complete at least some major milestone of the program within this short time frame.
The vast majority of business I have dealt with have hired a major consulting and system integration firm to start the enterprise architecture program, without having the need to hire an inside leader for enterprise architecture practice. I found this technique better for time-to-value than money-to-value, as the cost associated with hiring an outside consulting company is more. The consulting firms can partner up with the organization to do an assessment and architecture roadmap exercise. These initial activities include
(a) Identifying the business case for enterprise architecture
(b) Evaluating organizational readiness and its enterprise architecture maturity and
(c) Drafting an initial program and enterprise architecture roadmap plan to outline the to-be architecture state.
Within this short time period, the organization could hire leadership for the enterprise architecture practice. Once the practice leader is on-board, the architecture organization could establish practice principles such as enterprise architecture governance, architecture standards, process models, principles and guidelines. The enterprise architecture practice leader should establish structure to the architecture organization and define and communicate its mission, vision and service offerings. I have learned from many discussions that business often getting confused about enterprise architecture organization because the new EA organization’s purpose and its role were not communicated to the business entirely.
Once this new enterprise architecture organization is setup, at least at the core level, it can then validate the findings of the assessments and could decide developing detailed architecture program planning. Some of the activity that needed to be done at this stage is:
(i) Develop and establish Architecture Review Board (ARB) and COE’s
(ii) Define and validate To-Be Architecture roadmap
(iii) Select tools and technologies
(iv) Streamline vendors and partner channel
(v) Determine and plan hiring and training needs
(vi) Change, Quality, Monitor and Control
(vii) Architecture Sequence Planning
The leader could then decide if he or she wants to keep the consulting firm to complete the program or want to hire internal staff. It has seen beneficial for the organization to get some consulting help, if not all of it.
The biggest challenge in enterprise architecture program is to develop the enterprise architecture sequence plan. The sequence plan is very important for addressing business owners concerns about ‘when’ and ‘how’ things will be done and its time, costs and resources, so business owners could manage their own priorities. The enterprise architecture program itself depends on its own resources and other business priorities within the organization. These dependencies and overlaps sometimes take a great deal of time to sort out various differences and to get all teams agreed. It is highly recommended that the initial assessment and roadmap exercise address these issues upfront and should be delivering at least a draft sequencing plan at the end of the assessment phase. The end of this phase of enterprise architecture program becomes the big question for everyone. What now? How do we start enterprise architecture program? How to begin? You probably have got this pretty power point deck on your table from the consulting firm that has beautiful and colorful blocks of enterprise architecture roadmap graphics. Business leaders are now left out to figure this information and translate it into a detailed executable plan.
A sequence planning is a set of milestone deliverable critical path, together makes an enterprise architecture program to achieve its end goal. This sequence plan may be comprised with multiple smaller projects; some of them may be implementing certain software or hardware solutions, or some others introducing an entire new software or hardware architecture platform. The architecture sequence plan may not necessarily include details of beginning and ending, rather it generally gives you a broader understanding of projects that need to be executed in sequence and phased order for completion, its dependencies and may include a high level timeliness and costs associated with a particular phase.
For example, the plan may contain (a) business analysis (b) functional design (c) technical design (c) development (d) testing and production roll-out in an ordered track. The plan will explain the dependencies on business analysis on business process design or development activities. But it will leave out the details of particular business analysis such as business analysis need for identifying a specific business domain or a business function to start.
One of the basic principles that I have been following when these type of situation comes is to look at what kind of business domain we are in. Simply putting, for a consumer based company such as telecoms, banking, insurance etc, start with customer domain. For an inventory focused company such as pharmaceutical, CPG, automobile parts etc, start with product domain. Let me try to put some context to this. Let us talk about a major bank that is going through a business transformation program. Most likely, the critical problem area for business users are in getting accurate and timely information about its customers, a 360 degree view of their activities, such as a checking account, a saving account, a credit card, an investment account, an IRA account etc. An architecture program could potentially start by analyzing a common business process across this domain, such as customer acquisition process. You may start your business analysis either in sequence or in parallel. I found that conducting business analysis in parallel is complex and resource intensive than sequential analysis. It is easier to focus on one business process or business domain, then on to the next business process. To get the very best out of this exercise, it is recommended to identify common business process(es) that cuts across your majority of the business. [Continued]
I seriously learned about a lot of this, but that being said, I still believed it was beneficial. Sweet post!