An Organization’s Enterprise Architecture
Processes and the OODA Loop
Religious Organization’s Orienting Model
The Metaphysical Function
The Cosmological Function
The Sociological Function
The Pedagogical Function
The Methodist Denomination; an Example
The Catholic Church before 1500
Strategies (Based on the Christian Protestant Paradigm)
John Wesley, Adam Smith, and the United States
The Changed Mission
Who care about evil and social injustice
Do you only care about the bleeding crowd
How about a needy friend
I need a friend
Choosing a Mission, the Governance, and Infrastructure to Support a Religious Institution
The Three Great Principles
Organizational Architecture and the Protestant Church
A Mission Statement and the Strategies
Processes and Governance
Regulations: The “Must Meet” Requirements
Regulations the rudders of an organization
Arrow’s Paradox and Catch 22s
Reducing the Number of Regulatory Brakes but Keeping the Rudders
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.
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”.
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.
Agility and the Virtual Extended EnterpriseIn the 1990s, The Agility Forum of Lehigh University defined Agility as “The ability to successfully respond to unexpected challenges and opportunities.” The forum chartered a technical committe…
Over the past 6 years I’ve been developing a tool I call CARRMA(r) Basic. CARRMA stands for Computer Aided Requirements and Risk Management and Analysis. The reason I’ve been developing it is that I have had much experience with d…
I have just added an updated version of my paper on SOA and User Interface Services to “My Papers” page on my Blog.
I have added another paper to my list of papers. This one is on the central role of the Enterprise Architect in the Enterprise Portfolio Management Process and how Systems Engineering, System Architecture, and Enterprise Architecture are inter-re…
I added a new page (above and to the right). It contains links to some of my papers. I will be posting more from time to time. I am ordering the papers so that the readers might be better able to follow my discussion in each. I hope that helps. Let me know with comments, what you think.
The Papers include:
1. Enterprise Portfolio Management and Enterprise Architecture
2. The Role and Development of an Enterprise Architect: A Devil Advocate’s Perspective
3. Systems Engineering and System Architecture in an Agile and Short-cycle Transformation Environment
The Concepts of ValueIn the first chapter of my book, Organizational Economics: The Formation of Wealth, I describe three types of value, knowledge, capacity, and political (I also discuss these in three posts: Knowledge, Capacity, Political).&nbs…
The Current Mission of the CBO
Currently, the mission of the Congressional Budget Office (CBO):
Additionally, Enterprise Architecture proposes where develop, transform, reform, end or otherwise change the organizations’ missions, strategies, processes, and tooling. For the US Federal Government, (or any other organization of this scope and size), the EA process must be recursive, but traceable and integratable. The CBO is in the position with some of the responsibilities for doing this.
SOA and Cloud Computing, the Predicate to Model and Event Driven ArchitectureIn a recent post (see Functions Required in the Cloud PaaS Layer to Support SOA), I discussed two SOA patterns and two Cloud Computing patterns and showed how they are, in fac…