The Zachman framework is a grid of artefacts used to describe an enterprise architecture. This is illustrated with this posting but is also available from http://www.zifa.com/. I have heard it being referred to by one commentator as a caretaker's key holder. The key holder is a large rack where the caretaker hangs all his or her keys. Zachman does not require the whole grid filled. Nor is it necessary for only one artefact to correspond to each hook. It is therefore a fairly messy key holder. Nevertheless it is pretty handy. It prompts the architects to think about what is needed in a particular grid position. This is put well by Zapthink:
While we would not regard our organisation as mature in its enterprise architecture capability we have developed over the last few years. We have something to show for many of positions on the Zachman grid and we are using Telelogic System Architect to store and present some of these artifacts.
Well, the Zachman Framework has a little secret: few if any enterprises are able to flesh out more than a small handful of the 30 models associated with the boxes in the Framework. Instead, the Framework represents a best case, providing guidance for enterprise architects to tackle different aspects of their organization as the business needs dictate.
I will explain what we have in each of the cells in the Zachman grid. I will first deal with the two rightmost columns 'Time' and 'Motivation'. My organisation has not developed these columns very far. At the scope level there are corporate documents and at the technology level there are some details in project documents but these are not consolidated into an enterprise architecture. If we were doing Event Driven Architecture (EDA) or a business rules based architecture (http://www.businessrulesgroup.org/) we would have more emphasis on these aspects. There is still an advantage for our organization to work in these cells but it is not a priority. At the
business level we have an ends/means model detailing the detailed business rules of what we do. This fits in the "Business Model/Motivation cell. This is a big diagram and adorns a wall in the corridor.
Our approach is to document the top two rows fairly broadly and this is supplemented by project-specific materials in the lower levels. To some extent projects will drive our architectural direction. On the business model level we will often have both broad enterprise documents and specific project business modelling.
At the top 'Scope' row of the Zachman grid we have broad category lists based on the business.
Data: High level information model
Function: Core Business functions as presented in corporate planning documents. (These are not IT documents at all)
Network: Is a list of key locations. Within those locations there may be key organizational groupings.
People: At this level we identify key business roles. This is our starting point to determining security profiles.
The 'Business Model' row gets more detailed. Some of the diagrams at this level adorn the walls of my office.
Data: The enterprise information model gets more detailed and more specific. A number of projects have resulted in information models being provided in detail down to entity level but other modelling remains at a higher level.
Function: This is described by a high level business activity model. This is described as a hierarchy going down three levels. Also here we have a number of documented business process that mostly have been developed for particular projects.
Network: We do not have anything formal in place for this. Zachman suggests we should model business locations and linkages.
People: We need more in this place. I have a few organization charts but our administration of roles needs improvement and we need a better handle on these roles so we can provide appropriate access to our systems. Zachman also suggests a work flow model based on the role hierarchy in this cell.
The 'System Model' row is where we get into our logical design of our systems.
Data: Here we have a logical data model. This is project driven. Our enterprise data model at this stage is just the aggregation of a number of data models created for projects.
Function: This is the application architecture cell where a lot is happening as we move to an SOA. We have not completed our service model yet and most of what is in this space is project driven system models. This is also the space for a number of project specific artifacts such as use cases.
Network: We do not have much of a documented Distributed System Architecture. As our history was legacy mainframe the distributed system architecture was not particularly exciting but the need of this is growing and especially with SOA this architecture becomes more important.
People: Human interface architecture becomes more of a separate issue with SOA. We have a number of project specific documents on human interfaces but adoption of SOA and the push towards a common portal approach should be the incentive to publish something in this space. We have recently put some effort in documenting our application portfolio which is
also important for SOA.
The 'Technology Model' row is where we get or more physcal models of our systems.
Data: Our Data Stores Model is being developed which includes security classification, availability and currency information.
Function: My Zachman zealot advises this is where the software stack belongs. There is also some project activity here which will get consolidated into an enterprise architecture.
Network: We have a number of deployment diagrams which show what applications and parts of applications are deployed onto what hardware. Some of this is on my office wall.
People: Presentation Architecture is still project specific although we do have some user interface standards. Our target Presentation Architecture is likely to involve using a common portal and specific presentation layer technology.
The 'Detailed Representations' are mostly the working artifacts of the architecture:
Data: Database schemas. In the legacy applications we have the Bachman diagrams in the new applications we have ER diagrams and class diagrams. Increasingly with SOA these data definitions are done in XML.
Function: This includes the program code and other low level specification of the program logic.
Network: Network Architecture documentation is available and tends to be specific to a domain. (eg. File and printer server network, midrange network, telephony network, external data connections)
People: Security architecture is evolving. In many cases authentication is done through the one LDAP directory. The organization is still developing this so that it can provide role information as well.
This has been quick look through Zachman key holder. Much of the architecture remains unchanged under SOA. Our enterprise architecture focuses on business processes rather than application silos and this in turn supports SOA. The Application Architecture changes with SOA and many of the architectures and models around it are affected by the choice of SOA. Some logical data modelling may change to support the modelling of the service contracts but the resulting data model is likely to be similar to the one developed conventionally. There is increasing importance in the distributed system architecture and technology architecture as distributed processing becomes much more important in SOA.
The analogy of the key holder is not original I think I owe this to Glenn Smyth of Adelaide Bank
This is not the first time I have come up with a good posting topic only to find the Zapthink has already covered it for me. See also Lego and SOA.