In part 1 of this series I provided a ten thousand foot view of the project relative to the TOGAF ADM. In this post I’ll start with the proverbial peeling back of the onion. Using an integration project FYI Bank has made a strategic decision to address the challenge of their silos of IT systems by separating out their processes into business functions. One eerily business driver is the need for FYI Bank to improve business agility to respond to regulatory and market changes. The goal is to move the enterprise towards an infrastructure of building blocks of predefined services. To achieve this business executives of FYI Bank have also decided that a SOA strategy will best help meet this goal. The Bank’s executive steering committee has determined, that an attempt to implement a common enterprise architecture approach across the entire financial system would take a significant amount of time and effort, but they also believe that it is an achievable goal. Especially if the business organizations adopt a shared set of business and IT standards to ensure that a flexible SOA is possible. The steering committee has also approved the Lending Services organizations proposal for a Loan Application Portal Integration project, which is the pilot project for the SOA initiative. Additionally, FYI Banks Infrastructure Design Authority has selected to use IBM’s WebSphere Datapower SOA appliances as a new enterprise platform services capability. The enterprise architecture team has been engaged to support this organizational change to SOA and the introduction of this new technology component.
As the assigned architect responding to the business request for EA, I’ve identified some preliminary EA objectives around SOA governance. Now I intend to provide several model representation that will both inform and reflect architectural decisions going forward, as well as provide a new SOA governance capability around the architectural decision processes. One set of objectives is that the governance model will be developed incrementally, and will provide a reasonable set of constraints and compliance checks in the development of the business capability, and solution architecture. The measure for these objects has not been fully identified at this time. So the model representations that follow in this article are parts of what will be a comprehensive look across the architectural continuum. I’d like to encourage the reader to take a some time to review the various models. Their purpose is to communicate architectural decisions, by presenting various model views and perspectives in TOGAF and UML notations as well as observing the syntax of these notations. Which is an important part of doing architecture development..
With that statement in mind I’d like to bring up the subject of architectural modeling and tools. While it may feel a bit disjointed from the flow, I believe that it is an important aspect of the article, since I’ve already mentioned that you will be seeing several modeling representation, and more importantly these representations are guides for doing architecture.
Over the years of reading enterprise architecture blogs, and participating in various EA efforts. The topic of modeling tools has often been discussed. Sometimes it seems more like a religious debate, and I’ve read statements that a tool is somewhat superfluous to the EA tasks at hand. From my perspective I believe that a good tool is important to any craftsman, the mechanic, the carpenter, and yes enterprise architect. In order not to come across as dogmatic or bias about any particular EA tool. I feel that it’s more important to have a reasonable and specific list of requirements. I’ve taken this short list from RFP’s on previous EA projects.
…..•The tool shall provide a comprehensive coverage of several modeling notations.
………..(UML 2.0, Archimate, BPMN 2.0 and TOGAF elements and stereotypes)
…..•The tool shall provide a comprehensive coverage of modeling diagrams.
………..(TOGAF, UML, Free-form)
…..•The tool shall provide support for the TOGAF ADM.
…..•The tool shall provide relational management of modeling elements.
………..(Supporting model element integrity, and object reuse)
…..•The tool must provide a content repository, preferably relational database.
…..•The tool shall provide a means of publishing the model as Web content.
………..(Not necessarily providing a proprietary Web application client)
…..•The tool should provide constraints and guidance on modeling syntax.
…..•The tool should provide a flexible means of structuring, packaging and ordering of model elements.
The importance of this short list of requirements will become even more apparent as we transition through the ADM phases, but at this point I have another objective, which is to build a repository of reusable and relate-able artifacts that I will be able to use across the ADM iteration and the development life-cycle of the project. Another objective is to elevate our modeling representations above a academic, and Marka-tecture presentation approach, and use a rich set of notations that go beyond the notional Box & Line diagrams. All of which tend to be pasted into word documents and templates, that become stale soon after their release. In my thinking EA model representations should be iterative, dynamic, near real-time, and reference-able and reviewable by a larger audience at any time; preferably made available via a Web based reporting capability. Because ultimately the goal of the EA is to provide more that just architectural representations. The EA should also use the TOGAF ADM as a tool to guide the development of a set of prioritized and aligned objectives, and to provide the means for continually evaluating the understand the organization and its architectures, as well as to communicate this understanding to stakeholders, while moving the organization forward to its desired state.
So as a way communicating the FYI Bank Enterprise model. I have structured a repository as work packages that follow the TOGAF framework. In this regard a work package is a container that holds model representations as artifacts used in the implementation of the SOA governance capability. As the naming convention I will use the TOGAF phases as the parent work package. These will contain viewpoint packages, which are containers for model views. Model elements have will have meta-data attributes which will be present viable at some level in the fleshed out the designs. I will also provide a comprehensive view of the models published as Web documents. To give you a little more context I’ve included the following textual representation. The section labeled Model Diagrams represents a combination of TOGAF and UML model diagrams that are both reference-able and reusable as project artifacts. These are generally positioned at the package root level as they often provide different perspectives of the work package content. Again, I will post the evolving model as Web documents in upcoming blogs.
EA Context Model View
……..
……..
…………….
……..
……..
……..
……..
Note: Model Diagrams
… Repository Content Model View – Loan Application Portal Integration Project
… Project Structure View
… Content Meta-Model View
… Principles Model Domain View
… EA Principles Model View
Now let’s return to the project at hand. At present the FYI Bank has an enterprise architecture practice and several components of the TOGAF framework and ADM are already in place. In previous ADM iterations the EA team has established several core principles across multiple domains. The current enterprise organizational context is fairly well understood. Business frameworks such as Portfolio and Operational Management are also in place. Now the task ahead of the team is to introduce new capabilities for a SOA style architecture, as well as building the business solution for the Loan Application Portal Integration project. To guide the creation of the FYI Bank’s SOA governance model I’ll turn to the Open Groups SOA source book. The source book is the Open Groups collection of source materials for use by enterprise architects working with Service-Oriented Architecture. The documentation of the work being performed in this area of TOGAF can be found at; http://www.opengroup.org/soa/source-book/intro/index.htm If you have not already read the source book, you may want to take a moment to read through the introduction and become familiar with the framework of the documentation. I’d like to also note as a reminder, that I will be using both the Source Book and the TOGAF 9 framework throughout the project. The obvious implication of introducing the SOA source book is that the Loan Application Portal Integration project now has two areas of architectural concerns. The delivery of an effective business solution, which will be based on SOA governance standards provided in the new EA capability.
Recalling from the first blog the TOGAF ADM “crop circle” we were looking forward to the Preliminary phase where I would begin establishing the “where, what, why, who, and how we do architecture” in the enterprise. Since we are dealing with a change to our architecture practice we’ll start by turning to the TOGAF 9 Architecture Capability Framework for guidance and inputs. In reviewing the categories of the capabilities framework we see that this iteration of the ADM will impact the current design of all four domains of the architecture: Business, Data, Application, and Technology. I followed this activity with a review of the UML package model diagram, which outlined the Loan Application Portal Integration project structure, so I am now informed about which work packages will also impacted. A detailed explanation TOGAF’s Architecture Capability Framework Part VII can be found at: http://pubs.opengroup.org/architecture/togaf9-doc/arch/index.html
While examining the scope of change I’ve created a new Repository Content Model View, which is an abstraction while evolving the initial context for the next set of activities. Within the Preliminary phase work package I’ve now added a work packages for our new EA SOA principles, a EA requirements work package, a content-meta model view, to the Logical Layer Viewpoint, which has been reused in from our previous EA work. I’ve also identified the new EA capability as TOGAF SOA Governance.
In developing this model artifact the scope of the architectural change becomes more evident, in particular the change will impact the roles and responsibilities of several actors; business SMEs, business architects/analysts, and the architectural concerns covered by solutions/data/security/ technical architects, as well as system and software designers. In terms of roles and responsibilities and the decision as to what will be included in this iteration is still an unknown and under consideration at this time. What is known is that there are skills that are not outlined in the EA skills matrix.
The next category that I will cover in the capabilities framework is Architecture Compliance. Of the two subsections of compliance I start with a focus on the function of architecture, since this area addresses project-specific views of the enterprise architecture as used throughout all phases of the ADM. Here I will introduce what I consider a first class contextual model for the EA effort; the content meta-model. While the TOGAF Framework provides several excellent representations for this model. In my humble opinion, the significance of this model cannot be underestimated. So I’ve have included a content meta-model representation as part of our repository as an entity relationship diagram. I will use this model as sort of a planning tool, as I consider what objects will be included in the iteration, and the task that will be needed to develop those objects. If I’m required at some point in the project to provide a .mpp like project plan, I will use the content-meta model to flesh out the tasks for a work breakdown structure.
So throughout the execution of the ADM this artifact will play an important role in terms of planning EA activities, as well as maturing the EA content repository as we implement new business and architecture capabilities. During a previous EA project, a business stakeholder commented that at first glance; the content meta-model seems overwhelming, potentially producing a sense of “sticker shock”, or just too much information. My explanation was, that the model may be viewed as an object oriented version of a PM work breakdown structure, or it can also inform other agile PM methodologies by providing stories and task. For example, taken as a whole, the content meta-model is the basis for architectural epic. In a future blog I will suggest how a EA efforts can be integrated into a larger scale agile approach, as an architectural epic.
In the next model I will layout a Domain Principles Model Viewpoint, which provides us with another contextual view. I’ll use this to contain, communicate, and manage newly added SOA principles. Again we already have reusable work packages from previous iterations of the ADM. In this preliminary phase activity I’ve added a Principles of Service Design work package, which we saw was added to the Repository Content Model View. This also gives me traceability and scope by accounting for EA activities that will be used to flesh out the details of this work package. The principles that are added to this work package become a vital part of SOA governance.
Next I’ve started by adding several new model objects that are stereotyped <<principal>>. These elements are now part of the EA principles catalog as principle statements, along with the Rationale. These principles will be referenced and applied in the both the next phase, and future phases of the ADM. With he expectation that I will be adding more principles to this work package.
Given the significance of content meta-model, and the various newly added model artifacts. I’d like to suggest that we take a pause and review Part IV of the TOGAF framework. In Part 3 of the series I will build out more of the preliminary phase, by delivering the next version of the repository, I’ll link in Business Principles, Business Goals, and Business Drivers. We’ll add more details around SOA Governance, and I’ll then flesh out the details around the Architecture Definition Artifact. This will lead to a transition into the Architecture Vision Phase, where we will take up the decision to introduce IBM® WebSphere® DataPower® Integration Appliance as a strategic technology enabler for SOA.
