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.
Starting Enterprise Architecture Program
Once you have chosen a business area where you can start with, you could potentially conduct application portfolio analysis on that particular business domain. Within this portfolio analysis, you should be able to identify and collect application characteristics such as:
- Owners
- What operating business functions and processes does it support?
- Physical characteristics such as O/S, version, software
- Operating matrix such as cost, license, help tickets
- Shared service characteristics such as integrations, dependencies
At the end of this exercise you would have built a good meta-data about your application portfolio. This will help you to categorize your applications into “3C’s” (CORE, CRITICAL and CONSTANT)
CORE: These applications support the core business functions, such as Origination, Finance, Human Resource, and Customer Service etc. [example: Data Warehouse, ERP, CRM etc.]
CRITICAL: These applications support the critical daily functioning of the core business, without it, the business cannot operate and is at risk [example: Application Intake System, Order Entry System, Customer Support System – A data warehouse can be core but may be not critical for some business, as mostly it is historical data for analysis and data are loaded in batch]
CONSTANT: These are applications that do not make any differences for the business, or in other ways they are constant, whether they exist or does not exist it will not affect the daily operation of your business [examples: John Doe’s Access Database keeping track of Sale Department expenses, Mary Jane personalized and customized daily reporting for her boss, a custom data hub that is used by marketing department for keeping reference of old products]
The next step in the process is to categorize these applications into “4R”, RETAIN, REDUCE, REPLACE and RETIRE.
RETAIN: These are application that had previously classified as critical and (or) core supporting one or more business. These applications are built on a modern technology platform, and have seamless integration capabilities and are considered strategic long-term investments.
REDUCE: These are applications that are currently considered “stable” supporting one or more core business functions. They possess some limited integration capabilities and are not “at-risk”, and are not built on standards based technology. However, the continued use of these applications in long-term will need hardware and software upgrades and thus need its modernization. The application will not accept any new functionality and will reduce its offering of functionality in long-term until it is replaced and retired.
REPLACE: These are applications that are considered at risk of supporting one or more core or critical business functions in near-term. This application supports business processes that are considered critical, however are built on an older or legacy technology platform. These applications are need to be replaced and migrated into a newer and modern technology.
RETIRE: These applications may be a constant or core, and are not critical. The continued uses of these applications are considered not the best interest to the business. Some of the business processes may be considered to migrate into future plan.
The next step is to conduct business process re-engineering and design. During these stages, you may speed the design activities by starting your infrastructure design and infrastructure architecture. The To-Be Architecture guidance can be utilized to build your new technology and infrastructure capabilities. Thus, while you conduct business process re-engineering and probably some functional design, your infrastructure could be ready in parallel. Detailed functional and technical design follows the business re-engineering phase. At this time of the phase, you would have finished collecting some of the domain specific business (or all) requirements to further develop into technical services.
Most of today’s modern technology transformation program, SOA is an inevitable component. It would not be surprised if you will be transitioning your legacy applications into service based and standards based technologies. These may also include establishing some common shared services platform such as ERP, developing business intelligence and reporting capabilities, CRM and integration platform utilizing a standard based ESB and other security and monitoring tools and frameworks.
You could now introduce PMI methodology, Agile or SCRUM to develop your services. SOA development, data management and other areas of development are intentionally left out from this topic for later discussion. Now, you could go back and revisit some of your architecture governance and control processes for reviewing your design and build documentation. At this stage of the program, you may have well found the entry point to start your modernization program, as well as executing your enterprise architecture plan. Effectively, you just started your enterprise architecture program. Monitor, control, listen, learn, tweak and improve your processes as it progress.