My General IT Architecture Framework

Corporate Infrastructure Development

In general, an IT architecture should be part of the business vision projected by corporate officers.  That architecture should evolve as does the vision.  It's been my experience that IT architecture usually doesn't receive the attention it should.  Why?  Probably because most corporate visionaries, and even many middle managers, have their primary training in the principles of corporate law, accounting, business and/or engineering and don't have a very deep understanding of the fast-moving technologies that support those principles.

Operational Environment Simulation

As a result, the state of corporate IT architecture generally lags behind corporate business visions.

As shown in the figure at left, a corporation's enterprise architecture is constantly evolving -- even if the business vision and supporting processes happen to be stagnant.  When (generally, business driven) IT processes are identified as inefficient or in need of change to match a business vision (in the "Measure business process success" block, figure at left), a decision will be made to either perform process improvement or to perform what some call process re-engineering .  Process improvement is a relatively light-weight process change, while process re-engineering is generally lengthy and expensive.  From a project resource management perspective, I call these, respectively, "walk-ins" and "projects" -- reference, for example, A Complex Business Process with Interleaved Labor Resources and Labor Resource Optimization.  Regardless of the degree of process change, the enterprise architecture will be altered to some extent, which will force changes to related corporate entities (business and/or technical). 

Application Development Planning

The degree of change to these related corporate entities will depend on how successful the corporation has been at technical and corporate component isolation (see, for example, reference 1 and the simulated,  technical operation model above right).

My view of the cooperative effort necessary for the successful implementation of an IT "walk-in" job or of an IT "project"  is shown at right.  This is more a management/resource allocation/budget-level view, while the top figure presents the ongoing and iterative nature of the enterprise architecture.  Definitions of the terms used in this figure can be found in the site glossary.

Output from Operational Simulation

Typical results from modeling the operational characteristics of a specific IT architecture are shown in the figure to the left.  In the upper right of that figure is the network diagram of the system,  a system intended to provide Internet access to public information and extranet access to several corporate data stores that have customer personal information.  The model objectives were to identify bottlenecks and to show that customer response requirements would be met for various anticipated access types and customer loads.  The numerical information, on the figure's far right side, shows mean values and 95% confidence intervals for several system component categories, including expected system response times and expected component utilizations (##### represents a small value).  The graphs display temporal data from the last random input run, and indicate convergence to steady state leased line and mainframe utilization conditions.  Actual average system responses (as measured by Mercury LoadRunner and SiteScope, see Agile Application Development and Team Collaboration/Communication) fell within estimated 95% confidence intervals.

---

References:
  (1) "Understanding SOA with Web Services", Newcomer, Eric and Lomow, Greg, Addison Wesley, 2005.

Site managed with MyEclipse, a multi-language, multi-platform IDE