Agile Enteprise
Hurricanes and an Architecture for Process
The idea for this post came from a previous post on this blog regarding enterprise architecture and religious organizations.Definitions or Definitional TaxonomiesThere are three definitions that are needed to understand this post; the definition of Arc…
Enterprise Architecture, Systems Engineering, and Regulations: Process Rudders or Process Brakes
Regulations: The “Must Meet” RequirementsRegulations directly affect all organizations, products, systems, and services. Further, they can be a rudder guiding the organization or a brake causing the organization to stop making any progress in meeting i…
Enterprise Architecture, Systems Engineering, and Regulations: Process Rudders or Process Brakes
Regulations: The “Must Meet” Requirements
Regulations the rudders of an organization
Arrow’s Paradox and Catch 22s
Arrow’s Paradox
Catch-22
Reducing the Number of Regulatory Brakes but Keeping the Rudders
If You Want to Create an Enterprise Architecture; Don’t!
One of the last presentations I made as an Enterprise Architect for a major DoD contractor was to the Chief Architect of the US Veterans Administration. I walked in with a fully prepared presentation that was to take about 10 minutes of the time …
If You Want to Create an Enterprise Architecture; Don’t!
The Problem
The conundrum is that, in today’s technological environment, by the time an IT architecture team has mapped out (structured and ordered) an “as is” architecture, some, most, or all of the elements and data of the architecture will be obsolete and out of date. For something as large as a major corporation, a department within a state or the federal government, the cost and effort involved would require a tour de force on a very large perhaps unprecedented scale. This cost and level of effort would be such that the senior management would cut funding to the effort as a waste of time and money, since having an “as-is” architecture by itself produces little in value to the organization.
As can be found in the literature, there are many ways to “solve” or at least ameliorate the problem of creating an “as-is” architecture. For example, one of the best, that almost works, is to chop the organization into its components and create an “as-is” architecture for each component separately. Then try to stitch the architectures together. I’ve tried this and it works up to a point.
There is a truism in Systems Engineering, Systems Architecture, and Enterprise Architecture, “Optimizing the sub-systems will sub-optimize the system”. I have demonstrated this to many people many times and experienced it several times. But this is crux of the problem for those that try to create an Enterprise Architecture for a large organization.
The Solution
1. Define, delimited, and structured an initial set of classes and attributes for the Organization’s Enterprise Architecture. These should include:
- Its Charter, Mission, Goal
- Its Strategies for achieving its charter, mission, or goal
- Its Processes supporting its strategies
- Its Tooling and infrastructure
- Its Governance that affects any of the above, including:
- Internal Policies and Standards
- External Regulations and Standards
3. Here is the key to creating an “As-Is” Architecture by not creating it…Huh? Design and implement processes to capture the current state of strategies, processes, and tooling/infrastructure as part of review of funding for revision and upgrades to the current systems and processes.
4. When personnel in the organization propose a project insist that these personnel demonstrate the value of the process or procedure that they intend to update or upgrade. The “value” would include demonstrating which of and how the current product, system, or service enables the processes, strategies, and charter, mission, or goal of the organization. My experience has been that the initial attempts will be fuzzy and incomplete, but that as the number of proposed projects in the database (which is generally called the Asset Management System and on which the “as-is” architecture is built) increases both the completeness and clarity of the current enterprise architecture will increase.
The reason I say “Don’t” try to create an “as-is” architecture is that every 3 to 7 years every component of the organization’s information system will need replacement. This means that within 3 to 5 years simply by documenting and structuring the inputs from all of the efforts the organization’s “as-is” architecture will be synergistically created (and at minimal cost) [Sidebar: There will be some cost because the project proposers will need to think through how their current charter, mission, or goal and the strategies they support links to and supports the overall charter, mission, or goal of the organization. This is not necessarily a bad thing.] For large organizations, no matter how much time or effort is put into attempting to create an “As-Is” Enterprise Architecture, it will take a minimum of a year and a great deal of funding; so it simply makes no sense.
As this Enterprise Architecture evolves you will begin to see a number of things that managers want to obfuscate or hide completely. For example, a number of processes and component or sub-organizations will be demonstrated to be obsolete. In this case obsolete means that the process or component organization no longer supports any of the organization’s strategies or its goal. Since managers want to build or at least keep their fiefdoms they will not appreciate this much. Additionally, it will demonstrate which internal policies, regulations, and standards help the organization and which hurt it in meeting its goal. Again, the gatekeepers of these policies, regulations, and standards will object–strenuously.
But there are two more insidious problems that a good “As-Is” Enterprise Architecture will reveal, nepotism and the famous “Catch-22s”.
Nepotism
Catch-22
5. When the development and implementation team completes a project, and once it goes into operation, then as a final step in their effort, they should review the data they gave to the enterprise architect, revising the data to accurately reflect the “as-built” instead of the “as-proposed”. The as-built documentation must include all component, assembly or functional, and customer acceptance testing, and all post production required changes. This documentation will inevitably lead to additional class attributes of the Asset Management System and structure in the enterprise architecture.
6. As the Asset Management System and the Enterprise Architecture matures, management should prepare for a paradigm shift in the way projects and other efforts are proposed. This is where Enterprise Architecture really demonstrates how it can make the organization both more effective and cost efficient.
A mature enterprise architecture can serve as the basis for a dynamic business or organizational process model for the organization. Management can use this model to identify obsolete processes, (and as discussed) policies, regulations, and standards; ones that the organization should eliminate. Additionally, with the help of the Enterprise Architect, management can identify missing or inhibiting processes and tools, and identify bottlenecks and dams in process flows.
Further, they can model what happens when the missing and inhibiting processes and tools are added or when the bottlenecks are eliminated or reduced. This modeling will then indicate where there is a need for new efforts and to some degree the effectiveness and cost efficiency of such efforts. It’s a paradigm shift in that no longer to component or sub-units of the organization propose changes. Instead, senior management working with the Enterprise Architect and the component or sub-units will identify and fund efforts. They now have a way to measure the potential of the change in meeting the organizational goal, which means senior management has a better way of managing organizational change.
Finally, once management has identified targets for change or upgrade, the enterprise architect together with a system architect can define alternatives to meet the effort’s requirements. They can model alternative process and tooling changes to forecast which has the lowest potential risk, the highest potential return, the least disruption of current activities, lowest initial cost, lowest lifecycle cost, the most adaptable or agile, or any number of other targets defined by the senior management. This will make the organization much more cost efficient, and perhaps more cost effective; and this is the purpose of Enterprise Architecture,
To sum up, using this six step, high-level process is an effective way to create both an Asset Management System (an “As-Is” Architecture) and an effective Enterprise Architecture process; perhaps the only way.
Economies of Scale or Economies of Knowledge?
This Post is of an unpublished paper I wrote in 2008 and 2009. Dr. Chris Marai helped me by commenting and proposing edits. The concepts it presents and some sections of the writing I subsequently used in my book, Organizational Econom…
The Chief Process Office of an Agile Organization
The IDEF0 Pattern and the Organization’s Value EngineIn my book, Organizational Economics: the Formation of Wealth, I use the IDEF0 pattern to model the organization. This pattern has three internal components, Control, Process, and Mechanisms (t…