An Enterprise Architecture is a short phrase to identify and describe all the IT work products described across all the previous ROI areas that dealt directly with the creation, deployment and evolution of all the databases and business information systems in the enterprise. Specifically, the four ROIs that deal directly with the development of an Enterprise Architecture are:
- Project Management
- Information Systems Planning
- Data Centered Development and Management
- Manufacturing Integrated, Interoperable, and Non Redundant Data Models
Each of these ROIs cause the construction of significant components of an Enterprise Architecture.
The key difference between a traditionally developed Enterprise Architecture and these four ROIs is that while a traditionally developed Enterprise Architecture is accomplished almost always top-down, these four ROIs can be accomplished somewhat independently.
Whitemarsh holds, however, that Enterprise Architectures are often impossible to achieve deductively, that is, top-down. Top-down efforts require knowledge from the distant past to far into the future about what was, what is, and what will likely be concerning business missions, organizations and functions, about trends, staff, finances, products, sales, logistics, and the like.
Experience shows sadly, that memories are notoriously bad and the future always seems be either too cloudy or too rosy. In short, undertaking the effort to traditionally accomplish the top-down construction of an Enterprise Architecture is risky proposition that has a high probability of becoming “shelf-ware” as opposed to a guiding operational blueprint that is consulted often, and is constantly updated to accommodate unfolding realities.
So what’s an enterprise to do when charged by the board of directors, or CEO, or CIO to develop an enterprise architecture? Blow everything up and start over because a top-down enterprise architecture is likely to “change and/or obviate everything?” Likely not a good choice. Staff and resource budgets for such efforts will range from way too little to beyond sight with all intermediate budgets equally invalid.
Rather, the approach Whitemarsh recommends is to create the enterprise architecture inductively. Sort of, bottom up. The Whitemarsh approach is based on products either already built, or reasonably easy to build, on bite-sized projects that have immediately useful results, that are founded on realistic objectives, time-lines, and resources, and that will enable the creation of an enterprise architecture environment that is understandable, relatable to existing enterprise environments, and constructed such that the enterprise architecture can be evolved and maintained.