In the previous post, I defined a simple hierarchy for portraying the Enterprise:
- Strategy—What markets will we serve and how will we position ourselves in them?
- Business Model—What products and services will we sell? What characteristics will they have? How will they be priced? How will we publicize and advertise them?
- Operating Model—How will we produce what we will sell? What capabilities are required?
- Operational Architecture—How will we design and enable our organization to provide the capabilities needed?
I believe that understanding how this model is instantiated in the organization today (the As-Is) is the first step in understanding how ICT, among other things, fits, whether the fit could be improved and how it should be changed in response to changes at any level of the hierarchy. Expending the time and resources necessary to come to this understanding is viewed by many as a waste, resulting only in yards of shelfware and convoluted diagrams that will never see the light of day. They feel that the entire analysis and planning process should be forward-looking in order to establish a roadmap to guide the march to some optimal To-Be State.
Clearly, there have been many cases in which way too much time and effort have been spent to document As-Is. However, consider that the first question that must be answered when planning any initiative to transform to a new state is “Where are we starting from?” and you may reconsider. A trip from one town to the next may require a few minutes, but one from across the country to the same location is an entirely different matter. In addition, no part of the enterprise exists in a vacuum. Before you remove or replace something, you must know what is connected to it or you risk damaging or disabling critical processes or capabilities. All of this is part of understanding As-Is.
Modeling As-Is
Let’s create a prototypical model of a company that makes motor vehicles of various types, following the hierarchy outlined, above.
The Markets for our vehicles must be segmented. Not every licensed driver will have the same interests, desires or budget for a vehicle. The company’s marketing folks will segment the market based on what they believe are relevant criteria, such as gender, age, education, income level and geographical location. The numerous resulting market segments are all potential targets for our vehicles and we will have to design them to appeal on whatever criteria are deemed relevant, such as sportiness, performance, looks and price for whatever segments we choose to pursue.
The set of models and the variants we decide to manufacture will become our Product set, with each variant mapped to the market segment(s) to which it is targeted.
Let’s assume that the Capabilities required to make and sell a vehicle are common to all: Design, Source Parts, Assemble, Quality Control, Sell, Transport, Deliver and Service. These will all be enabled in some way and mapped onto our Product portfolio. Some models will use common parts and some will require parts specific to them only. Some will require specialized assembly procedures and some not. Some subset of vehicles will be sold through common dealerships and some will be sold through specialist outlets.
Finally, people are assigned to roles in various processes supported by enabling automation—Business Intelligence and analytical software, CAD systems, ERP systems, Manufacturing and Assembly automation, Accounting and HR systems, and so forth—some of which may be shared and some of which may be unique to specific parts of the enterprise. And, of course, data is flowing into and between repositories everywhere.
Beneath it all is a set of supporting infrastructure—buildings, services, data networks, servers, security services and so on. Some of it is physical and some is virtual. Some is managed by ICT and some by other departments within the enterprise.
Ultimately, the goal for the as-is model is to be able to trace from market segment to products to capabilities to processes to people to systems to infrastructure. If we have this graph, we should be able to use it to guide us to the relevant information necessary to assess things such as:
- How many different CAD systems do we have?
- Who is using them and for which of our vehicles?
- How much do they cost us?
- Can we decommission some of them, consolidate our users and save some expenses?
Or, more existential ones like:
- If we want to make a new line of vehicles can we take a slice of our existing enterprise capabilities and re-purpose them for that?
- What would be involved?
- How would we fill in any gaps this might leave in our existing operations?
- What are the risks and costs?
As-Is Modeling Costs and Benefits and Reduction of Risks
When faced with a change in environment, a threat or an opportunity, we should have, at a minimum, a guide to what we need to assess to answer the many questions that will arise. If we do not have as-is documented, we may need to do a fire drill just to establish some basis for identifying and prioritizing the discovery and analysis required for formulating a response or transformation plan. This will extend the time required to respond and greatly increase the risk of omissions or errors that could compromise the quality of the decisions or plans that ultimately result.
If our auto manufacturing company has a lead time of 24 months from concept through initial delivery, what is it to do when faced with a competitor announcing that it will introduce a new model that is likely to substantially grab market share from one of our lines in 18 months? The options may range from revamping existing models to make them more competitive to building completely new ones. For each option considered, several implementation scenarios may be viable. We might re-purpose one of our plants or retool several to accommodate new parts and features. There will be impacts along the link between every impacted node in our as-is model. Systems may require modified interfaces to accept new data, people may be assigned to temporary roles, accelerated design and development processes may be initiated and modifications to all sorts of elements in the existing enterprise architecture may be needed.
This sort of decision-making is iterative. It is likely that various combinations of alternatives will be evaluated, revised and re-evaluated. If valid as-is data is not available, then collecting, reviewing and quality-controlling it may contribute to delays or unnecessary iterations exactly when it is least convenient and most costly. Under duress, expedient and sub-optimal decisions might be made that could cost the company considerably.
In the end, the discipline of maintaining an as-is model pays off by speeding decision velocity, increasing responsiveness and reducing the risks of making sub-optimal, time-constrained decisions. It may also facilitate inward-facing assessment of the organization’s structure and performance, exposing opportunities to improve that might not be visible otherwise. How much time and resource a company should commit to it is a function of a number of things, such as the volatility of the markets in which it competes and the innovation rates in its primary production processes.
The As-Is model is something that should be overseen and managed by EA but which must be contributed to by processes that create change in the enterprise’s architecture—changes in organization structure, new product lines, updated application systems, revised workflows. It’s quite possible to overdo it and operate at the molecular level, incurring excessive expenses. EA wisdom is setting a filter to capture data likely to be relevant at the strategic and tactical levels but ignoring day-to-day changes that don’t really impact the enterprise’s ability to evolve or respond when it has to. It’s very much the same thing as setting increasing limits on the spending authority of more senior managers to avoid wasting their time on low-risk decisions.
EA should contribute to managing the enterprise’s program and project portfolio, helping to evaluate the initiatives brought forward for funding and dictating those implementation decisions that might compromise the enterprise’s to-be architecture. ICT and EA should have a symbiotic relationship—they need to share a lot of information and many of the initiatives that EA will be called upon to evaluate will have substantial ICT components. In addition, many of the architects, such as the Business, Process, Solution and Data Architects that formulate and oversee implementation of the initiatives into which EA has input, usually report within the ICT organization, increasing the need for tight collaboration between EA and ICT.
In future posts, I will explore the roles of EA and ICT in planning for To-Be and options for ICT structure that may compliment or impair its value within the enterprise.