In my earlier post I argue that to provide value quickly, architecture needs to be thought of in the context of local needs more than enterprise needs. Here are five implications of architecting locally: Solve a local problem, not the … Continue reading →
Here’s one of my favorite pictures of bad architecture that I use frequently in my presentations to non-architects. These pictures are from an elevator at Terminal 3 at JFK. Clearly there are at least three departments at JFK, each with … Continue reading →
A Pattern for Development and Transformation Efforts
Consequently, as shown in Figure 1, I call this process pattern “The Three-legged Stool” pattern for development and transformation. I will discuss each sub-process as a role with requirements. Therefore, this is what I see as the needs or requirements for the process and the skills for the role. In my next book, I will discuss more about how these can be done.
- Requirements Identification, Management, and Verification/Validation (see various other posts as well)
- Risk Management
- Configuration Management
There is a significant issue with designers and implementers, they attempt to create the “best” product ever and go into a never ending set of design cycles. Like the Systems Engineering “analysis paralysis”, this burns budget and time without producing a deliverable for the customer. One part of this problem is that the SMEs too often forget is that they are developing or transforming against as set of requirements (The “What’s Needed“). In the hundreds of small, medium, and large efforts in which I’ve been involved, I would say that the overwhelming percentage of time, the SMEs never read the customer’s requirements because they understand the process, procedure, function, or method far better than the customer. Therefore, they implement a product/system/service that does not do what the customer wants, but does do many functions that the customer does not want. Then the defect management process takes over to rectify these two; which blows the budget and schedule entirely, while making the customer unhappy, to say the least. The second part of this problem is that each SME role is convinced that their role is key to the effort. Consequently, they develop their portion to maximize its internal efficiency while completely neglecting the effectiveness of the product/system/service. While I may be overstating this part somewhat, at least half the time, I’ve seen efforts where, security for example, attempts to create the equivalent of “write only memory”; the data on it can never be used because the memory cannot be read from. This too, burns budget and schedule while adding no value.
Again, I will discuss solutions to this issue in the last two sections of this post.
- “The best of all leaders is the one who helps people so that, eventually, they don’t need him.
- Then comes the one they love and admire.
- Then comes the one they fear.
- The worst is the one who lets people push him around.
The Way This Works Today: The Program Management Control Pattern
The first way is to give control of the effort to manager. This is the “traditional” approach and the way most organization’s run development and transformation efforts . The effort’s manager manages the customer’s programmatic requirements, (budget and schedule), so the manager plans out the effort including its schedule. This project plan is based on “the requirements”, most often plan includes “requirements analysis”.
[Rant 1, sorry about this: My question has always been, “How is it possible to plan a project based on requirements when the first task is to analyze the requirements to determine the real requirements?” AND, I have seen major efforts (hundreds of millions to billions) which had no real requirements identified…Huh?]
The Program or Project Manager tells the Systems Engineer and Developer/Implementer when each task is complete; because that’s when the time and or money for that task on the schedule is done, regardless of the quality of the work products from the task. “Good” managers keep a “management reserve” in case things don’t go as planned. Often, if nothing is going as planned, the manager’s knee jerk reaction is to “replan”; which means creating an inch-stone schedule. I’ve seen and been involved in large efforts where the next level of detail would be to schedule “bathroom breaks”. This method for resolution of “analysis paralysis” and “design the best” will almost inevitably cause cost and schedule overruns, unhappy customers, and defective products because the effort’s control function to control costs and schedules.
The Program Management Control Pattern
Figure 2 shows the Program Management Control Pattern. The size of the elipse shows the percieved importance of each of the three roles.
To be able to “Control” the effort, the Program Manager requires many intermediate artifacts, schedules, budgets, and status reports, which use up the resources of the efforts and are non-valued work products, the customer might look at these artifacts once during a PMR, PDR, CDR, or other “XDR” (Rant 2: Calling these review Program Management Reviews, instead of some type of Design Review”, Preliminary, Critical, etc., demonstrates the overwhelming perceived importance of the programmatic requirements by Program Managers.) I submit that all of these intermediate artifacts are non-value added because 3 months after the effort is completed, the customer or anyone else will not look at any of them except if the customer is suing the the development or transformation organization over the poor quality of the product. All of these management reviews require resources from the Developers/Implementers and the Systems Engineers.
One extreme example of this management review procedure was the procedures used in development of new aircraft for the US Air Force and Navy during the 1980s and 90s–sometimes facts are stranger than fantasy. The DoD required some type of “Development Review” every 3 months. Typically, these were week-long reviews with a large customer team descending on the aircraft’s Prime Contractor. Program Management (perhaps, rightly) considered these of ultimate importance to keeping the contract and therefore wanted everyone ready. Consequently, all hands on the effort stopped work 2 weeks prior to work on status reports and presentation rehearsals. Then, after the “review” all hands would spend most of an additional week reviewing the customer’s feedback and trying to replan the effort to resolve issues and reduce risk. If you add this up, the team was spending 1 month in every 3 on status reporting. And I have been part of information technology efforts, in this day of instant access to everything on a project where essentially the same thing is happening. Think about it, these aircraft programs spent one third of their budget, and lengthened the programs by 1/3 just for status for what? Intermediate artifacts of no persistent value–Who looked at the presentations of the first Preliminary Design Review after the aircraft was put into operations? [Rant 3: Did the American citizen get value for the investment or was this just another Program Management Entitlement Program funded by the DoD?]
Second, as shown in Figure 2, the Systems Engineering role is substantially reduced in the perception of the Program Manager. An example of this was brought home to me on a multi-billion program, when I asked the chief engineer where the requirements were stored, he quoted the Program’s Director as saying, “We don’t need no damn requirements, we’re too busy doing the work.” This Director underlined this thinking; he kept hiring more program management, schedule planners, earned value analysts, and so on, while continuous reducing then eliminating the entire Systems Engineering team and leaving only a few System Architects. He justified this by the need to increased control and cost reduction to meet his budget [Rant 4: and therefore to get his “management bonus”–no one ever heard of the Design or a System Engineering Bonus]. Actually, I’ve seen this strategy put into play on large (more than $20M) three programs with which I was associated and I’ve heard about it on several more within the organization I was work for and in other organizations, over the past 10 years.
Another program that I worked on as the Lead Systems Engineer that had the same perception of the Systems Engineer (including the System Architect’s role within the Systems Engineering discipline/role). It is an extreme example of all that can go wrong because of lack of Systems Engineering. This effort was development of a portal capability for the organization. It started with a that had 10 management personnel and myself. They articulated a series of ill-thought-out capability statements, continued by defining a series products that had to be used (with no not identification of Customer System or IT Functional requirements), with a 6 weeks schedule, and ended with a budget that was 50 percent of what even the most optimistic budgeteers could “guessitmate”. They (the three or four levels of management represented at the meeting) charged me with the equivalent of “Making bricks without straw or mud in the dark”, that is, creating the portal. Otherwise, my chances of getting on the Reduction In Force (RIF) list would be drastically increased.
Given that charge, I immediately contacted the software supplier and the development team members from two successful efforts within the organization to determine if there was any hope of the effort within the programmatic constraints to accomplish the task. All three agreed, it could not be done in less than 6 months. Faced with this overwhelming and documented evidence, they asked me what can be done. The result was based on their “capability” statements, and “Requirements (?)” documents from the other two projects, I was able to cobble together a System Architecture Document (SAD) that these managers could point to as visible progress. Additionally, I used a home grown risk tool to document risks as I bumped into them. Additionally, I instituted a risk watch list report on a weekly basis, which all the managers ignored.
At this point one fiscal year ended and with the new year, I was able to have the whole, nationwide, team get together, in part, to get everyones requirements and design constraints. Additionally, I presented an implementation plan for the capabilities I understood they needed. This plan included segmenting the functions for an IOC build in May, followed by several additional several additional builds. Since this management team was used to the waterfall development process, the rejected this with no consideration; they wanted it all by May 15th. In turn, I gave them a plan for producing, more or less, an acceptable number of functions, and an associated risk report with a large number of high probability/catastrophic impact risks. They accepted the plan. The plan failed; here is an example of why.
One of the risks was getting the hardware for the staging and production systems in by March 15th. I submitted the Bill of Materials (BOM) to the PM the first week in February. The suppliers of the hardware that I recommended indicated that the hardware would be shipped within 7 days of the time the order was received. When I handed the BOM to the PM, I also indicated the risk if we didn’t get the systems by March 15th. On March 1st, I told him that we would have a day for day slippage in the schedule for every day we didn’t receive the hardware. The long and the short of it was that I was called on the carpet for a wire brushing on July 28th when we had the program held up because of lack of hardware. Since I could show the high-level manager that, in fact, I had reported the risk (then issue) week after week in the risk report she received, her ire finally turned on the PM, who felt he had the responsibility.
The net result of these and several other risks induced either by lack of requirements or lack of paying attention to risks resulted in a system that was ready for staging the following December. Management took it upon themselves to roll the portal into production without the verification and validation testing. The final result was a total failure of the effort due to management issues coming from near the top of the management pyramid. Again, this was due to a complete lack of understanding of the role of Systems Engineering and Architecture. In fact, this is a minor sample of the errors and issues–maybe I will write a post on this entire effort as an example of what not to do.
In fact the DoD has acknowledged the pattern shown in Figure 2 and countered it by creating System Engineering Technical Advisory (SETA) contracts.
The Utility of Program Management
None of the latter three types of leaders, as described by Lao Tzu, can perform perform this service to the team, the ones I call in my book, the Charismatic, the Dictator, or the Incompetent. In other words, the PM can’t say and act as if “The floggings will continue until morale improves”.
Instead, the PM must be a leader of the first type as described by Lao Tzu and as I called in my book as “the coach or conductor”. And any team member can be that leader. As a Lead Developer and as a Systems Engineer, I’ve run medium sized projects without a program manager and been highly successful–success in this case being measured by bringing the effort in under cost, ahead of schedule, while meeting or exceeding the customers requirements Yet, on those none of the programs, for which I was the lead systems engineer and which had a program manager and who’s mission was to bring in the effort on time and within budget, was successful. On the other hand, I’ve been on two programs where the PM listened with his/her ears rather than his/her month and both paid attention to the System Requirements; those efforts were highly successful.
The net of this is that a coaching/conducting PM can make a good team better, but cannot make a bad team good, while a PM in creating better projects plans, producing better and more frequent status reports, and creating and managing to more detailed schedules will always burn budget and push the schedule to the right.
- If a development or transformation effort focuses on meeting the customer’s system requirements, the effort has a much better chance of success than if the focus is on meeting the programmatic requirements.
- If the single fundamental assumption is changed from “All the requirements are known up front” to “Not all the requirements are known up front” the effort has the opportunity to be successful or much more successful by the only metric that counts, the customer is getting more of what he or she wants, and that increases customer satisfaction.
- If the development or transformation effort can roll out small increments will increase the customer’s ROI for the product, system, or service.
- Having a Program Manager, who’s only independent responsibility is managing resources be accountable for an effort is like having the CEO of an organization report to the CFO; you get cost efficient, but not effective products, systems, or services. [Final Rant: I know good PMs have value, but if a team works, that is because the PM is a leader of the first type: a coach and conductor.] Having a Program Manager that understands the “three legged stool” pattern for development or transformation, and who executes to it will greatly enhance the chance for success of the effort.
My first career out of college was as a nonprofit lobbyist in Washington, DC. It was an education in many core principles of politics, including the famous saying from former House Speaker Tip O’Neill, “all politics is local.” Speaker O’Neill … Continue reading →
TOGAF often refers to Strategic Planning without specifying the details of what it consists of. This document explains why there is a perfect fit between the two.
Strategic Planning means different things to different people. The one constant is its reference to Business Planning which usually occurs annually in most companies. One of the activities of this exercise is the consideration of the portfolio of projects for the following financial year, also referred to as Project Portfolio Management (PPM). This activity may also be triggered when a company modifies its strategy or the priority of its current developments.
Drivers for Strategic Planning may be
· New products or services
· A need for greater Business flexibility and agility
· Merger & Acquisition
· Company’s reorganization
· Consolidation of manufacturing plants, lines of business, partners, information systems
· Cost reduction
· Risk mitigation
· Business Process Management initiatives
· Business Process Outsourcing
· Facilities outsourcing or in sourcing
· Off shoring
Strategic Planning as a process may include activities such as:
1. The definition of the mission and objectives of the enterprise
Most companies have a mission statement depicting the business vision, the purpose and value of the company and the visionary goals to address future opportunities. With that business vision, the board of the company defines the strategic (e.g. reputation, market share) and financial objectives (e.g. earnings growth, sales targets).
2. Environmental analysis
The environmental analysis may include the following activities:
· Internal analysis of the enterprise
· Analysis of the enterprise’s industry
· A PEST Analysis (Political, Economic, Social, and Technological factors). It is very important that an organization considers its environment before beginning the marketing process. In fact, environmental analysis should be continuous and feed all aspects of planning, identify the strengths and weaknesses, the opportunities and threats (SWOT).
3. Strategy definition
Based on the previous activities, the enterprise matches strengths to opportunities and addressing its weaknesses and external threats and elaborate a strategic plan. This plan may then be refined at different levels in the enterprise. Below is a diagram explaining the various levels of plans.
To build that strategy, an Enterprise Strategy Model may be used to represent the Enterprise situation accurately and realistically for both past and future views. This can be based on Business Motivation Modeling (BMM) which allows developing, communicating and managing a Strategic Plan. Another possibility is the use of Business Model Canvas which allows the company to develop and sketch out new or existing business models. (Refer to the work from Alexander Osterwalder http://alexosterwalder.com/).
The model’s analyses should consider important strategic variables such as customers demand expectations, pricing and elasticity, competitor behavior, emissions regulations, future input, and labor costs.
These variables are then mapped to the main important business processes (capacity, business capabilities, constraints), and economic performance to determine the best decision for each scenario. The strategic model can be based on business processes such as customer, operation or background processes. Scenarios can then are segmented and analyzed by customer, product portfolio, network redesign, long term recruiting and capacity, mergers and acquisitions to describe Segment Business Plans.
4. Strategy Implementation
The selected strategy is implemented by means of programs, projects, budgets, processes and procedures. The way in which the strategy is implemented can have a significant impact on whether it will be successful, and this is where Enterprise Architecture may have a significant role to play. Often, the people formulating the strategy are different from those implementing it. The way the strategy is communicated is a key element of the success and should be clearly explained to the different layers of management including the Enterprise Architecture team.
To support that strategy, different levels or architecture can be considered such as strategic, segment or capability architectures.
Figure 20-1: Summary Classification Model for Architecture Landscapes
This diagram below illustrates different examples of new business capabilities linked to a Strategic Architecture.
It also illustrates how Strategic Architecture supports the enterprise’s vision and the strategic plan communicated to an Enterprise Architecture team.
Going to the next level allows better detail the various deliverables and the associated new business capabilities. The segment architecture maps perfectly to the Segment Business Plan.
5. Evaluation and monitoring
The implementation of the strategy must be monitored and adjustments made as required.
Evaluation and monitoring consists of the following steps:
1. Definition of KPIs, measurement and metrics
2. Definition of target values for these KPIs
3. Perform measurements
4. Compare measured results to the pre-defined standard
5. Make necessary changes
Strategic Planning and Enterprise Architecture should ensure that information systems do not operate in a vacuum. At its core, TOGAF 9 uses/supports a strong set of guidelines that were promoted in the previous version, and have surrounded them with guidance on how to adopt and apply TOGAF to the enterprise for Strategic Planning initiatives. The ADM diagram below clearly indicates the integration between the two processes.
The company’s mission and vision must be communicated to the Enterprise Architecture team which then maps Business Capabilities to the different Business Plans levels.
Many Enterprise Architecture projects are focused at low levels but should be aligned with Strategic Corporate Planning. Enterprise Architecture is a critical discipline, one Strategic Planning mechanism to structure an enterprise. TOGAF 9 is without doubt an effective framework for working with stakeholders through Strategic Planning and architecture work, especially for organizations who are actively transforming themselves.
This is another slide I use in my “Architecture 101” deck. The point that I make about this particular picture is that architecture is not just about performance. In this example, both the slide and the gravesite perform exactly as … Continue reading →
Photo by Tim Hipps, FMWRC Public Affairs I’m a little ashamed to admit I’ve spent far too much of my career debating colleagues on the merits of capability versus process. In the worst example, I engaged in an intense debate … Continue reading →
A good many of the issues result from a poor understanding by economists and Finance Engineers of the underlying organizational economic model embodied in Adam Smith’s work, which is the foundation of Capitalism. The result of this poor understanding is an incomplete model, as I describe in Organizational Economics: The Formation of Wealth.
“Cost avoidance is a cost reduction that results from a spend that is lower then the spend that would have otherwise been required if the cost avoidance exercise had not been undertaken.” ]
- Quantifiable–Metrics that organization is currently using to measure its process(es) performance and dependability that will predictably change with the development or transformation; the metrics will demonstrate the benefits (or lack thereof). This type of metric will provide hard, but not financial, evidence that the transformation has benefits. Typically, the organization knows both the minimum and maximum for the metric (e.g., 0% to 100%).
- Measurable–Metrics that organization is not currently using to measure its performance, but that should measurably demonstrate the benefits of the development or transformation. Typically, these metrics have a minimum, like 0, but no obvious maximum. For example, I’m currently tracking the number of pages accessed per day. I know that if no one reads a page the metric will be zero. However, I have no idea of the potential readership for anyone post because most of the ideas presented here are concepts that will be of utility in the future. [Rant 5: I had one VP who was letting me know he was going to lay me off from an organization that claimed it was an advance technology integrator that “he was beginning to understand was I had been talking about two years before”–that’s from a VP of an organization claiming to be advanced in their thinking about technology integration–Huh….] Still, I have a good idea of the readership of each post from the data, what the readership is interested in and what falls flat on its face. Measurable metrics will show or demonstrate the benefits, but cannot be used to forecast those benefits. Another example is of a RAD process I created in 2000. This process was the first RAD process that I know of, that the SEI considered as Conformant; that is, found in conformance by an SEI Auditor. At the time, I had no way to measure its success except by project adoption rate (0 being no projects used it). By 2004, within the organization I worked for, that did several hundred small, medium, and large efforts per year, over half of them were using the process. I wanted to move from measurable to quantitative, using metrics like defects per roll out, customer satisfaction, additional customer funding, effort spent per requirement (use case), and so on, but “the management considered collecting this data, analyzing and storing it to be an expense, not an investment and since the organization was only CMMI level 3 and not level 4, this proved infeasible. [Rant 6: It seems to me that weather forecasters and Wall St. Market Analysts are the only ones that can be paid to use measurable metrics to forecast, whether they are right wrong, or indifferent–and the Wall St. analysts are paid a great deal even when they are wrong.]
- Observable–Observable is the least quantitative, which is to say the most qualitative, of the metric types. These are metrics with no definite minimum or maximum. Instead, they are metrics that the participants agree on ahead of time–requirements? (see my post Types of Requirements.) These metrics are really little more than any positive change that occurs after the transformation. At worst they are anecdotal evidence. Unfortunately, because Financial Engineers and Managers (for reasons discussed above) are not willing to invest in procedures and tooling for better metrics like those above, unless they are forced into it by customers, (e.g., requiring CMMI Level 5), Enterprise Architects, System Architects, and Systems Engineer must rely on anecdotal evidence, the weakest kind, to validate the benefits of a transformation.
“Every revolutionary idea evokes three stages of reaction. They can be summed up as:
–It is Impossible—don’t Waste My Time!
–It is Possible, but not Worth Doing!
–I Said it was a Good Idea All Along!”]
Consequently, “proving” that the engineering and implementation of the transformation actually reduced the cost, and not the “manager’s superior management abilities” is difficult at best–if it weren’t the manager’s ability, then why pay him or her the “management bonus” [Rant 8: which is were the Management Protective Association kicks in to protect their own].
The Benefits Measurement Process
As usual, I will submit to the reader that the keys (culturally and in a business sense) to getting the the organization to measure the success (benefits) of its investment decisions and its policy and management decisions is twofold. The first high-level activity is a quick, (and therefore, necessarily incomplete) inventory of its Mission(s), Strategies, Processes and tooling assets. As I describe in Initially implementing an Asset and Enterprise Architecture Process and an AEAR, this might consist of documenting and inserting the data of the final configuration of each new transformation effort as it is rolled out into an AEAR during an initial 3 month period; and additionally inserting current Policies and Standards (with their associate Business Rules) into the AEAR. Second, analyze the requirements of each effort (the metrics associated with the requirements, really) to determine the effort’s success metrics. Using the Benefits Context Matrix determine where these metrics are incomplete (in some cases), over defined (in others), obtuse and opaque, or conflicting among themselves. The Enterprise Architect would present the results of these analyses to management, together with recommendations for better metrics and more Process Effective transformation efforts (projects an programs).
The second high-level activity is to implement procedures and tooling to more effectively to efficiently observe and orient the benefits through the metrics (as well as the rest of the Mission Alignment/Mission Implementation Cycles). Both of these activities should have demonstrable results (an Initial Operating Capability, IOC) by the end of the first 3 month Mission Alignment cycle. The IOC need not be much, but it must be implemented, not some notional or conceptual design. This forces the organization to invest resources in measurements of benefits and perhaps, in which component the benefits exist, control, process, or mechanisms.
Initially, expect that the results from the Benefits Metrics to be lousy for at least three reasons. First, the AEAR is skeletal at best. Second, the organization and all the participants, including the Enterprise Architect have a learning curve with respect to the process. Third, the initially set of benefits metrics will not really measure the benefits, or at least not effectively measure the benefits.
For example,I have been told, and believe to be true, that several years ago, the management of a Fortune 500 company chose IBM’s MQSeries as middleware, to interlink many of its “standalone” systems in its fragmented architecture. This was a good to excellent decision in the age before SOA, since the average maintenance cost for a business critical custom link was about $100 per link per month and the company had several hundred business critical links. The IBM solution standardized the procedure for inter-linkage in a central communications hub using an IBM standard protocol. Using the MQSeries communications solution required standardized messaging connectors. Each new installation of a connector was a cost to the organization. But, since connectors could be reused, IBM could right claim that the Total Cost of Ownership (TCO) for the inter-linkage would be significantly reduced.
However, since the “benefit” of migrating to the IBM solution was “Cost Reduction“, not Increased Process Effectiveness [RANT 9: Cost Avoidance in Finance Engineering parlance], Management and Finance Engineering (Yes, both had to agree), directed that the company would migrate its systems. That was good, until they identified the “Benefit Metric” on which the management would get their bonuses. That benefit metric was “The number of new connector installed“. While it sounds reasonable, the result was hundreds of new connectors were installed, but few connectors were reused because the management was not rewarded for reuse, just new connectors. Finance Engineering took a look at the IBM Invoice and had apoplexy! It cost more in a situation where they had a guarantee from the supplier that it would cost less [RANT 10: And an IBM guarantee reduced risk to zero]. The result was that the benefit (increased cost efficiency) metric was changed to “The number of interfaces reusing existing connectors, or where not possible new connectors”. Since clear identification and delineation of metrics is difficult even for Increased Cost Efficiency (Cost Reduction), it will be more so for Increased Process Effectiveness (Cost Avoidance).
For example, BAMM used in conjunction with SOA-based Services will enable the Enterprise Architect to determine such prosaic metrics as Process Throughput (in addition to determining bottlenecks) before and after a ttransformation. [RANT 11: Management and Finance Engineering are nearly psychologically incapable of allowing a team to measure a Process, System, or Service after its been put into production, let alone measuring these before the transformation. This is the reason I recommend that the Enterprise Architecture processes, Like Mission Alignment be short cycles instead of straight through one off processes like the waterfall process–each cycle allow the Enterprise Architect to measure the results and correct defects in the transformation and in the metrics. It’s also the reason I recommend that the Enterprise Architect be on the CEO staff, rather that a hired consulting firm.] Other BAMM-derived metrics might be the cost and time used per unit produced across the process, the increase in quality (decreased defects), up-time of functions of the process, customer satisfaction, employee satisfaction (employee morale increases with successful processes), and so on. These all help the Enterprise Architect Observe and Orient the changes in the process due to the transformation, as part of the OODA Loop-based Mission Alignment/Mission Implementation process.
Definition of a RequirementA Requirement is a measurable expression of what a customer wants and for which the customer is willing to pay. Therefore, a requirement has three attributes:It has a description of what the customer wants or …
Business Rules and Process FlowIn a recent post, A Model of an Organization’s Control Function using IDEF0 Model, The OODA Loop, and Enterprise Architecture, I briefly described the Governance and the Policy Management processes within the context of t…
I am going to talk about a consequence of the hype cycle that seems to be missed by many. I will use an anecdote to illustrate the point…
About 10 years ago, I was engaged on a short assignment to review a new technology organization’s customer service programs. The company had grown rapidly in a new market that was now maturing. They had 3 customer service systems. They had 4 main customer groups served through 4 sales channels. Each channel used different business processes to execute the same activities and accessed all three systems. The IT solutions had grown organically with the business and were a mess! But now, with the market maturing, there were mainstream solutions from major suppliers that could replace these systems that were starting to constrain the business. However, the cost of resolving this, $15M, was seen as too expensive.
A few years later, the organization had lost its competitive position, had moved from number 1 to number 2 and was taken over by a foreign competitor entering the market. With a more complex product portfolio, more customer groups, a more complex sales model, the customer services systems were now seen as a major constraint to business growth. I happened to be engaged through another consultancy to look at the problem again. This time the cost of sorting it out had grown to $80M. Again the executive board decided that this was too expensive.
Recently, the organization merged with a major competitor. I heard that they had embarked yet again on a program to replace their legacy customer service systems. The market is now much more complex with many more products, it is also more competitive with tighter margins. The systems have grown in complexity since the last attempt to sort them out. I suspect the cost this time will be $150M or more. A ten times increase in cost in ten years. More importantly, the organization was the market leader 10 years ago but now it is in 3rd position with a likely drop to 4th.
The key point is that everything that you build before good practice emerges is likely to be poorly designed and poorly built. It should be thrown away and you should start over. If you don’t you will inevitably perpetuate bad practice. Future development will be compromised because time pressures to deliver tactical business change and the constraint of the legacy. And the cost of replacing it to deliver strategic business change will grow over time.
Sometimes I wonder why there is so much legacy. The answer is obvious if you overlay the adoption cycle with hype cycle…
So what are the lessons:
- It is never too late to sort out your legacy
- Don’t build on bad practice
- The so called first mover advantage can be a handicap
- Build knowledge before building solutions
Many Business Analysts are using the IIBA’s BABOK 2.0 (Business Analyst Body of Knowledge ) which contains information about a Requirements Management process, from identifying organizational situations that give cause to a project, through to starting the requirements gathering process, to delivering a solution to the business or a client. TOGAF 9 from an Enterprise Architecture viewpoint also provides some techniques to gather requirements to equally deliver business solutions. This paper illustrates the two processes, defines the mapping between the two approaches and identifies gaps in each.
BABOK 2.0 Knowledge Area (KA) 4 covers Requirements Management and Communication which “describes the activities and considerations for managing and expressing Requirements to a broad and diverse audience” (The other KAs: Plan Requirements, Management Process, and Requirement Analysis will not be included here).
The tasks from this KA “are performed to identify business needs (the why of the project; whereas requirements are the how), the state the scope of their business solutions, ensure that all stakeholders have a shared understanding of the nature of these solutions and that those stakeholders with approval authority are in agreement as to the requirements that the business solution shall meets.”
It manages a baseline, tracks different versions of Requirements documents, and trace requirements from origin to implementation.
This area includes five steps described below.
1. Manage Solution Scope and Requirements
In this step, we “obtain and maintain consensus among stakeholders regarding the overall solution scope and the requirements that will be implemented”. Requirements may be baseline following an approval and a signoff. That means that all future changes are recorded and tracked, and the current state may be compared to the baselined state. Subsequent changes to the requirements must follow a Change Management process and will require additional approval. As changes are approved, a Requirements Management Plan may require that the baselined version of the requirements be maintained in addition to the changed Requirement. Additional information is often maintained such as a description of the change, the person who made the change, and the reason for the change. As requirements are refined or changed as the result of new information, changes will be tracked as well.
A signoff formalises an acceptance by all stakeholders that the content and presentation of documented requirements is accurate and complete. This can be done in a face to face meeting.
2. Manage Requirements Traceability
Traceability consists of understanding the relationship between Business Objectives, the requirements, the stakeholders, other deliverables and components to support the business analysis among other activities. It also allows documenting “the lineage of each requirement, its backward and forward traceability, and its relationship to other requirements”. The reasons for creating relationships are “Impact Analysis”, and “Requirements coverage and allocation”. A coverage matrix may be used to manage tracing.
3. Maintain Requirements for re-use
Requirements re-use is another important aspect in the process and there is a need to manage knowledge of requirements following their implementation, identify the requirements that are candidates for long-term usage by the organisation. “These may include requirements that an organisation must meet on an ongoing basis, as well requirements that are implemented part of a solution” (e.g. regulatory, contractual obligations, quality standards, service level requirements, etc.). Each will have to be clearly named, defined, and available to all analysts.
4. Prepare Requirements Package
This step consists in selecting and structuring a set of requirements “in an appropriate fashion to ensure that the requirements are effectively communicated to, understood and usable” by the various stakeholders. This Requirements Package could have different forms such as a documentation (can be managed in a Requirements Repository), presentations, templates, etc.
5. Communicate Requirements
This step relates to the communication of requirements to the various stakeholders for a common understanding. It may happen that new requirements have to be considered.
The BABOK bundles Requirements Communication together with Requirements Management.
Requirements Analysis is another KA which describes “how we progressively elaborate the solution definition in order to enable the project team to design and build a solution that will meet the needs of the business and stakeholders. In order to do that, we have to analyze the stated requirements of our stakeholders to ensure that they are correct, assess the current state of the business to identify and recommend improvements, and ultimately verify and validate the results”. BABOK 2.0 Requirements Analysis being not really covered within TOGAF 9, there are no comparisons done at this stage.
Within TOGAF 9, the objective of the Requirements Management activity is to define a process whereby all kinds of requirements, including most notably business drivers, concerns, and new functionality and change requests for Enterprise Architecture are identified, stored, and fed into and out of the relevant Architecture Development Method (ADM) phases. As such it forms part of the activities and steps carried out in each of the ADM Phases. Architecture requirements are subject to constant change, and requirements management happens throughout the entire Enterprise Architecture implementation lifecycle.
It is important to note that the Requirement Management circle denotes, not a static set of requirements, but a dynamic process.
As indicated by the Requirements Management circle at the centre of the ADM graphic, the ADM is continuously driven by the Requirements Management process.
Enterprise Architecture has specific techniques to gather requirements. TOGAF as a framework uses a method based on what we call a “Business Scenario” which is used heavily in the initial phases A & B of the ADM to define the relevant business requirements and build consensus with business management and other stakeholders.
A Business Scenario ensures that there is a complete description of business problem in business and architectural terms. Individual requirements are viewed in relation to one another in the context of the overall problem; the architecture is based on complete set of requirements that add up to a whole problem description; the business value of solving the problem is clear and the relevance of potential solutions is clear.
Below is a mapping between the two approaches.
BABOK 2.0 sets up a framework for the requirements development and management, which seems to appear as a standard used by many organizations around the world. Between TOGAF 9 and BABOK 2.0, there is almost 1:1 correspondence but there may be more details and activities in the first one. TOGAF is a methodology whereas the BABOK is methodology agnostic, so it can be tricky to translate between the two but nothing prevent an Enterprise Architecture team to use this analogous technique.
If an organization follows the TOGAF methodology and Business Analysts use BABOK, the later will provide a lot of useful information, as a reference; BABOK won’t give you direction for an Enterprise Architecture.
Sources: Chapter 4 IIBA’s BABOK 2.0, TOGAF 9