When people ask me what I do when I am not golfing, I size up the situation and answer accordingly. If it is with people that are familiar with the IT industry, I tell them that I help people create architectural designs for their IT solutions to ensure success with their projects. If is with people that would not understand, or are further removed from IT Architecture, I respond with “I draw pictures.”
Most often, there is a brief discussion about CAD software, but it follows with a discussion on how I do a lot of what falls in between. I create a lot of models as part of what I do, and educate and mentor IT resources in their use of models and IT Architecture. Many that know about the Zachman framework, also know that there is little chance of ever completing the framework. My discussions always center around doing what is necessary and what gives them greatest gains at the earliest possible times.
Today, I want to tell you which models you have to have. There are many to choose from, but if you need a starting point, let’s start here. To put this into perspective, the Zachman Framework is most often discussed in the context of Enterprise Architecture. It is interesting that when looking closely at it, the models associated with each cell are most likely to be used in system specific situations rather that from an enterprise level.
Top 10 Models You HAVE to Have!
Why Should You Model Software?
- Create and communicate software designs before committing additional resources
- Trace the design back to the requirements, helping to ensure that the team is building the right system
- Practice iterative development, in which models and other higher levels of abstraction facilitate quick and frequent changes
When Do You Model?
- To better understand the business or engineering situation at hand (and to craft a better system)
- To build and design a system architecture
- To create visualizations of code and other forms of implementation
What Should You Model?
Ah, yes, the crux of this article.
This will not be a comprehensive article on modeling but rather discussion about the general topic and what you need to include on your checklist. There is no prescribed tool here — use what is appropriate and available.
It doesn’t matter whether these are done in Rose, Visio, PowerDesigner, ErWIN, System Architect, etc. It is an incredibly important component of an architect’s role in any system environment.
The top ten models that you should always have both in your IT environment and for your systems, from a top down business to technology order are:
- The Conceptual Model/Diagram. By this I mean the high level business model that describes the major things, concept areas, domains, etc. that your enterprise cares about. This may be known as a domain model. It should be drawn as simply as possible.
- The Use Case Diagram.You may require several Use Case Diagrams to describe the actor’s interaction with business functions.This will serve as a road map for those who need to document the use cases, as well as a picture for the business team involved in your project.
- The Class Diagram. Take the conceptual model to base classes store for discussions with users. Update as part of the architectural review for each system built very little changes should occur. This is different than the class diagram required to model data in your enterprise or project, and should be more at an enterprise level. Major classes only “things” or major areas of business should be included. Think departments in your organization and the major business “things” they are responsible for, produce or interact with.
- The Activity Diagram. Notice the intersection at FUNCTION (how) and Business Model. Activity, State and Interaction diagrams are shown here. If you have experience with these diagrams, you all know that these are the UML replacements for business flow charts and business process diagrams.
- The Application Architecture diagram – a diagram that describes conceptually how the application will be architected – components, parts, pieces.
- The Logical Data Model. This may be created using a logical data modeling tool. If you want to solely use UML models, an Entity Class Diagram is required here. In the past, I’ve had my share of wars with a plotter printer.I’ve created a massive class diagram that describes the classes required for a large custom payments system. The entire enterprise is not included on this diagram, but details about the payments system itself, and periphery classes of closely related business entities are.The primary goal of the entity class diagram is to help a client get ready to enable themselves for web services integration with their financial applications and vendor and government health systems.
The near-term goal is to allow the analysts who will be developing use cases to have enough information about the data and relationships so that the project team can have a consistent view amongst analysts, and so that the design may include all of the data classes within the UI and horizontal prototypes.
- The Physical Data Model. This should be created using a physical data modeling tool that generates DDL or schema scripts. Creating the physical data base using something like a server management tool is possible, but incredibly inefficient. This model will save valuable DBA time. Changes are simply when this exists, and now developers can have a pictorial view of what the applications need to access.
- The Deployment Diagram. The value of this diagram is going to depend on the type of application or system you are building. At the enterprise level, this diagram can be used to generally describe the enterprise and the major deployments that exist. At a system executable level, it can help to detangle a complication delivery exercise.You might layout the components that need to be installed by server and create relationships between them to help yourself with putting together a sequenced plan or checklist. Either way if you haven’t used this one, try it on your next deploy and you will save yourself some sanity.
- The Technology Architecture Model. In the case of the technology architecture, we may only be looking at the component and deployment the answer again is “it depends”. This model should exist for your technical environment.If your organization is very large, you may need multiple versions, but at the minimum, you should have one at the enterprise level. If you can’t show the major technology components of the system you are focused on, you should create one that clearly shows the same layers, but includes the specific moving parts you are documenting.
- The Network Architecture. This one should be at an Enterprise level, at granularity high enough to see the machines and major networks that will carry or support the system in question. It should include the network topology, showing how resources are distributed, as well as loops to various machines.It should depict location if there are multiples, and major network components such as firewalls and appliances at as low a level as is possible to show meaning for the system at hand. Protocols and specifics to the protocols (for example firewalls, DMZ’s, etc for internet networks) will be different depending on the environment on which the system will be deployed.
There are many other optional models. The mapping I’ve shown in the Zachman Framework indicates that all of the key models I’ve listed fall in the Data, Function and Network abstractions (Zachman columns.) There are other important models that will aid your cause, but you need to get started and get people moving in the right direction. The other models can be described as supporting, and are dependent on the situation before declared required.
As far as the perspectives go (Zachman rows), we’ve covered the business, application (system) and technology architectures. Documentation showing traceability, why decisions were made, how architecture addresses concerns provide critical information.
