by Clyde Miner, Logicon
Want to Have Some Fun?
Ask an Information Technology executive about the corporate data topology. Huh? Ask about the value-added business mappings for each IT piece part. Say what? Finally, ask to see the enterprise's operational process model. Game, set, and match. Sadly, this isn't a game and it isn't fun. It's people playing with real dollars who are generally not knowledgeable about the characteristics of the business their expensive infrastructures are ostensibly supporting. It's people who are seduced by the rush of another MHz uptick (yawn) in cycle speed. It's people who begin each IT planning cycle with penetrating questions such as, "How many servers have we got?"
The Model
Any organization and its composite support levels (e.g., Architecture) can be modeled:
* Layer 1: Business Model - Products/Services
* Layer 2: Informational Model - Data Definition/Organization & Business Processes
* Layer 3: Operational Model - Organization & Resource Alignment
* Layer 4: Architectural Model - Overall IT Design
* Layer 5: Infrastructure - Tools/Products/ IT Processes
Model Layer Definitions
The Business Model defines what the organization's business goals are, what outputs (e.g., products, services) the organization expects to produce, and any known constraints which must be considered toward achieving those goals/outputs (e.g., time, budget, federal regulations). It defines the near term and strategic requirements of the organization (i.e., the organization’s business).
An Informational Model identifies how the organization’s business works. Information/process analysts review the business model goals/outputs and determine what data, process entities and integration need to be defined to optimally achieve them. The emphasis is on information. The data and process structures of the organization (i.e., how the data works and reacts to various systematic behaviors) that produce and deliver information is considered. The informational model shows resources, processes, process interaction, atomic data, and data associations being used to drive the business today. It typically shows the lack of data integration.
An Operational Model defines the business structure (e.g., the organization chart) and allocates the resources (e.g., people, materials) to that structure so as to optimally work the model defined in Layer 2. This implies that an effective organizational structure is one which aligns itself with the processes defined in Layer 2. This paradigm shift has to occur, albeit not without cultural pain. Interestingly, it’s in this layer where most organizations err by imposing a structure which, although traditional, is not aligned with Layer 2 since Layer 2 was not embraced as an operational driver.
An Organizational Model examines the processes and data handling identified from Level 2 and attempts to optimally execute those processes by establishing various operational entities. These entities traditionally include business offices, engineering, administrative, research, etc. These entities are integrated in a fashion which is both cost-effective and functional. Integration takes place in two forms:
* Physical integration is organizationally-based. It examines issues of what organizations need to be deployed (e.g., R&D) and how those organizations should operate in relation to each other.
* Logical integration is informationally-based. It examines issues (from Layer 2) such as what data and associated data formats are needed for various organizations to perform their jobs. It should spawn an organization which is based less on people and function and more on process and data. It is from schema that organizations will move to flatter process-based structures rather than more customary function-driven hierarchical structures.
An Architectural Model examines the outputs from Layers 2 and 3. It defines an optimum IT topology for those informational processes which need to be accelerated or demand a level of accuracy which likely will not be achieved if handled continually by "human" resources. Examples of IT Architectures include Client/Server, Distributed Processing, and Open Systems.
The Infrastructure defines simply those IT implementation pieces which represent "today's" technology decisions. As we move through the genesis of IT technology, this layer is the least stable, as technology piece parts seem to have half-lives of mere months.
Considerations for Architecture in the Generic
Users want their IT system to behave like a value-added utility. They demand an intuitive interface and a predictable cost-effective result. Consequently, a good IT architecture:
1. addresses the organization’s business and information needs. An architecture which ignores the business or its processes will fail.
2. allows for an infrastructural instantiation to be implementationally and operationally cost effective. ROI here is a function of Total Cost of Ownership (TCO).
3. is migratable from the "as-is" architecture.
4. is migratable to IT's future. As Technology changes, faster, smarter, and cheaper methods and tools become a given. An architecture has to be scaleable to accommodate new products and tools which implicitly suggest the architecture in which they are most productive.
From a design perspective, the architecture should:
1. Separate data from function.
2. Provide a means to measure its effectiveness.
3. Be modular to a level where each element performs no more than one or two discrete functions.
4. Separate data processing functions into discernible tasks that are generic and self-sufficient.
5. Document itself. If it can't, it probably isn't right.
6. Keep data "generated" by an organization managed by that organization.
The Future?
The future depends solely on the future of the supported business. If allowable, though, consider an architecture that extends the notions of "objects" and "distribution." Why? Because successful IT architectures are becoming more and more focused and dispersed. Standardization for architectural interfaces is becoming a reality. Standards, compatibility, best-of-breed, plug 'n play, and integratability are all architectural characteristics of an IT solution which seeks the best cost-effective solutions for its customer. This is achievable through an architecture in which components are viewed minimalistically. Applications and data are divided and subdivided until they reach almost an atomic level. These entities then have discrete singular purposes which allow for mix-and-match solutions.
Get to work. But do so in the order suggested by the model. Ignoring the model is also fun…if you like high stake games where the ante may be your career.
About the Author
Clyde Miner is the Chief Technologist for Logicon, a division of Northrop Grumman Corp. He is currently writing a book called 'Computer Games' which focuses on the "why we're in the mess we're in" foibles of Information Technology.
Other Articles:
- IT Architecture - Where, What, Why?
- The Making Of A Successful Enterprise Technical Architecture
Further german information can be found here.
|
