My experience and research indicates that high-performance businesses view IT as a strategic asset—a source of both operational excellence and competitive advantage. So as an IT leander how do I help top management adopt that mindset and achieve greater business value from IT. My objecttive: IT is not merely a cost center but a critical contributor to the business, focused on improving business value and performance.
First things is to get together a plan we can all see and understand. Typically this has been called an Enterprise Architecture plan. Enterprise architecture defines the vision, principles, standards and roadmap that guide the selection, deployment, operation, and refreshment of technologies within an organization.
On Wikipedia, it is stated that this is the definition that comes from the MIT Center for Information Systems Research:
Enterprise Architecture is the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the firm’s operating model.
A little more reading will take you to dozens of Enterprise Architecture Frameworks with a dizzying array of acronyms. See this Wikimedia graphic.
One of the most recent releases of an Enterprise Architecture Framework is the TOGAF 2009 (http://www.opengroup.org/togaf/). On the other hand one of the oldest that orinated back in the 1980's is the Zachman Framework and although it started much earlier, it has stood the test of time and is still relevant today.
It is relevant because of it's simplicity and structure. The Zachman Framework for Enterprise Architecture is a schema or diagram that depicts the intersection between two classifications. The first is the fundamentals of communication found in the primitive interrogatives: What, How, When, Who, Where, and Why. The second involes the transformation of an abstract idea into an instantiation and are labled: Identification, Definition, Representation, Specification, Configuration and Instantiation. The result looks like this:
I like this model (as mentioned in a previous Blog) because it is clean and pure in definition and not complicated by a bunch of methodology etc. The only challenge comes in some of the terminology in the cells and down the left hand side. Everyone understand the top row of who, what, why, when, where and how. But then getting the terminology straight for what the perspectives going down are results in a number of options. Don't worry, hopefully I will make sense of it before we finish this post.
Regardless of what framework you choose it is VERY IMPORTANT to realize:A framework does not make architectural design an automatic process, however it is an invaluable aid to experienced and knowledgeable IT Architects, Developers and management.
I am going to use the Zachman Framework. It appears that the Zachman Framework has become almost a standard in the IT industry for classifying the artifacts developed in enterprise architecture. It is a logical structure for classifying and organizing the design artifacts of an enterprise that are significant to its management. Typically these perspectives of the Zachman Framework have been defined as:
- Scope (Contextual) - Planner
Presents the Scope of the Enterprise architecture (Enterprise View) - Business Model (Conceptual) - Owner
Documents the system view of the architecture. (Business View) - System Model (Logical) - Designer
Documents the logical design of the architecture (Logical View) - Technology Model (Physical) - Builder
Presents the physical implementation plan for the architecture (Physical View) - Detailed Representations (Out-of-context) - Subcontractor
The detailed specifications for the instantiation (Specification View) - Functioning System
These are the actual, working systems within your organization.
The views are arranged top to bottom with the Scope defining the highest level models and the Functioning System being the actual deployed hardware and software. However I am going to add a little more to the diagram and fill it in with what I see as needed in each of the blocks and add an additional column on the left for who is going to use or own the information in each Perspective row as shown below:
There can be a negative side affect to all of this in this Agile world of ours...These 36 cells can easily lend itself to a documentation heavy approach. Even with this potential pitfall, I believe that it provides very good guidance for your modeling and development efforts because it reminds you of the critical issues which you need to address. So the old idiom of KISS (Keep It
Simple Stupid) needs to be applied to keep from going overboard on documentation, models etc. It is not a requirement to create documentation or artifacts for all of the cells. But it is very important that you at least consider the issues for each cell.
As Scott Ambler shows here using the Zachman Framework can be Agile.
Classification. Organization. Covering all Angles. This is what the Zachman Framework really promotes. Unfortunately, what the executive "C-Level" individuals really want to know varies greatly by their discipline or operational viewpoint. However, there is almost a 100% chance that if you have used the Zachman Framework to help develop your Enterprise Architecture plan, that you will have thier answers and more.
Remember: Don’t make the initial architectures, policies, rules and processes so involved and difficult that no one will follow them let alone maintain them.
Architecture. When constructing a building it is important that the foundation be built with care since every other component of the building relies on it. The enterprise architecture is the foundation of the modern business and requires the stability and flexibility gained through planning and design. Just like a poor building foundation can result in a structure that is unstable, unable to be expanded or added on to, and in many cases, unfit for living. The same is true for poor enterprise architecture. Today many businesses suffer from a complete lack of EA. There never was one and stuff just got built and today these businesses have an inflexible, inefficient, high maintenance foundation.
Unlike a physical foundation of a large building where complete repair may be impossible, in the information world, you can fix things. We are blessed (and cursed) with a typically short 4 year lifespan on most hardware. In other words, it is never too late to start developing your enterprise architecture, planning and implementing one piece at a time. As you begin the journey and start "filling in" your Zachman Framework, it will quickly become clear where to focus first and what the dependencies are etc.
When it comes to planning the information technology architecture, the “pay now or pay later” rule applies. Put money and time in up front in defining the architecture to avoid frustration and expense later in the process. Remember...never too late to start! When things are bad, sometimes it seems easier to just keep things the way they are...bad...but it is not. Change ensures future viability for your company and a solid provable return on any technology investment. It allows us to minimize downtime, eliminate technical incompatibilities, and ensure smooth operations.
Defining, developing, and maintaining an enterprise architecture is a big job. Put dedicated, experienced personnel on this job that understand the entire technology picture and the interdependencies between applications, database, network, security, and infrastructure. A strong Business sense and ability to interact outside of IT is also very important.
In summary I would encourage you to look carefully at your enterprise. Do you understand it and can you explain it and prove it to the entire executive management team? Can your software developer understand where the routine he just built fits in the big picture? Does operations support understand the criticality of each system? If you hesitate with any of these answers then it is probably a good idea to spend some time reading up on Enterprise Architecture and how to use the Zachman Framework to help you.
