Describing a rich EA framework and process using a standard object oriented development approach.
Recently I had had an interesting conversation with a solution architect around the TOGAF framework and the ADM. I was asked the following question: “Can you provide a short but reasonable description for tailoring the framework while instantiating the ADM as a practical implementation?”. This was certainly an interesting challenge given the scope and depth of the TOGAF ADM.
So I took up the task with the concept of “dogfooding”. Why not apply tools and techniques describe in the ADM and other methods as an approach. So, I started with an enterprise architecture modeling tool that supports TOGAF modelling elements and UML notation. I then applied object oriented analysis techniques to flesh out a set of contextual models.
My objective; provide a concise and practical example of the ADM using a model based approach for developing architectural capabilities. Which is the same method for developing a solution architecture that delivers a business capability.
TOGAF for all practical purposes may be thought of as a tool box of artifacts. With the underlying ADM as the process by which those artifacts are prescribed and applied. In general this is often expressed by the use of the TOGAF crop circle diagram; artifacts excluded.
While the crop circles offer a simplified standard and popular expression of the ADM. Its a bit difficult to translate that viewpoint into a description for a practical implementation. Especially if someone new to implementing the ADM. And when adding the depth and richness of the ADM another challenge arises. Particularly, how to provide simplified contextual viewpoints which correlate to TOGAF artifacts as deliverables.
In offering one solution to these challenges I began by creating a couple of architectural context models by:
- Creating a work package viewpoint of high-level requirements.
- Creating a work package viewpoint of domains used in the ADM, which are abstracted as static components.
By abstracting domains into components, I’m then able to create architectural definitions for each domain, which I will then tailor for this particular implementation. I also added component interfaces, which will provide the means for describing the interaction between the domains in the execution of the ADM.
For each domain component an architectural definition would include.
- The role(s) that are responsible for implementing the domain components capability
- The interface definition in terms of the required artifact data.
- The responsibility of the domain component which is mapped to the ADM.
- A mapping of the architectural capability being delivered by the domain component.
By providing these static viewpoints I now have the ability to scope the work that is will be required for developing new architectural capabilities. What make this a value added exercise is this process of moving from the descriptive aspects of the framework to a prescriptive application for implementing the artifact the will support the ADM.
This approach also has some ancillary benefits.
- Establishing a basic model driven capability to the architectural practice.
- Establishing the use of industry standard modelling notations.
- The building of an enterprise repository of architecture assets.
- Sets the foundation for building upon a concrete implementation of a tailored ADM.
My next but not final step is to create an artifact dependency viewpoint. I will use this model to reason about the artifacts as deliverables in terms of component interfaces. The essential attribute of this model is the design by contract approach. The intent is to use the role that is encapsulated by the domain component as the implementation for the interface. This is a bottom up design which enables an agile approach to tailoring what is “just good enough” for each deliverable relative to the domains interface. The implementation can then be determined by the capability of the role, and the scope of the work for a sprint. In performing this exercise I now realize the architectural component definitions from the previous activity in terms of role(s) and responsibilities. Which then delivers several outputs for the ADM.
- Identify the key or values added deliverables for each ADM domain.
- Provide input to a RACI matrix for the underlying ADM process.
- Identify the skill level that will be needed for the implementation.
- Tailor the scope of deliverables and the process.
Conclusion
In using some relatively straightforward and simple object oriented analysis techniques. I believe that one can reasonably create a concise description of a complex rich and mature framework and process such as the TOGAF ADM. And in this proposed solution I am “dogfooding” the same approach for building toward a solution architecture that delivers a business capability.
It also seems to me, that this sort of exercise can also yield significant value at several other levels of architectural development. For example, by decomposing the high-level requirements into User Stories and adding a process model. A current architectural practice can augmented or even assessed for improvement. Which demonstrates one way to integrate an EA capability with an agile project management methodology.
