In this article I address some of the the final elements and models in this iteration of the Preliminary phase. At this point I would like to comment about the ADM as an iterative process. In regards to Architectural Definition which includes an ideation / inception iteration. At this point in the role of Business Architect I have taken some time to consider each phase of the ADM in preparation for the next iteration. For the most part I have started to what are the possible artifacts that will be developed in the subsequent iterations. For this I generally use a heat map styled document for planning and charting progress. This artifact provides a planning snapshot for upcoming gate reviews as the transition made between iterations. Up to this point I’ve only lightly touched on the some of the essential aspect of architecture effort with a focus on governance. It should be noted that the degree of “doneness” for any particular artifact that has been produced up till this point will vary. And because I am publishing the repository content as Web documents from the modeling tool. Stakeholders are not constrained to a particular deadline for reviewing the content of the EA repository.
This is a type of model driven approach where the repository is used for dynamically doing architecture development. This is a concept that will require time for organizational socialization, and the shift in organizational behavior may be slow. This is an aspect of the TOGAF that I opted not to cover in this series. But organizational change should not be underestimated. However, the benefits of this approach are significant in that it promotes agility as a capability as well as an organizational behavior.
One key value add for the artifact development heat map, is that is can be easily used in conjunction with agile project management methods. For example, aligning the heat map with PM methodologies provides a means for enabling the use of the architecture artifacts, and governance checkpoints, and can serve as the basis for creating architectural epics. This is also my way of creating a plan for integration points for introducing new SOA capabilities into the already established business planning, portfolio, and operations management frameworks. For example, by the end of this article I will have developed an architectural definition that will address the integration points of Architectural Direction, Structured Direction, and Architectural Governance. The heat map will provide me with measure of the degree of completeness that is needed to satisfy these framework interfaces.
At this point I’m wondering if you have asked why the heat map does not specify a list of artifacts. The reason behind this is the use of a modeling tool to improve development velocity. All artifacts are produced as models. While there may come point where a document may be called for. I’ll simply use the tool to generate a model report (See: the link to the content at the end of the article). Another situation is where the tool may not provide coverage for an architectural discipline that is not expressed in TOGAF, UML, or BPNM notations. This situations will come up a little later in the article
It’s not uncommon that business drivers, and their related goals and objective are defined outside the formality of the ADM. This is the case with FYI Bank. And since context is always an important dimension of any project, I will build out a set of work packages with various Goal views. In this first model view I’ve placed the Enterprise Architecture work package at center.
The reason for placing the Enterprise Architecture work package at the center of this this view, is based in the the TOGAF modeling syntax, in which Drivers create Goals, and then Objectives are used to realize the stated Goals. From this construct we derive capabilities. In this view I am emphasizing that the TOGAF enterprise governance capability is a contributor to the delivery of enterprise business capabilities from the Corporate, Project and Infrastructure business domains. This is a contextual representation of how EA governance is tied to a heterogeneous part of the enterprise. It provides a model view that allows us to reason and make decisions about the governance capabilities and their impact on business segments that will be engaged in delivering the business solution. Placing the Enterprise Architecture work package is at the center of this model, show that by using the TOGAF ADM we have a comprehensive means for considering where the governance model will be implemented and used across the enterprise.
It’s from this contextual view that I take my starting point for applying various level of abstraction in considering the Drivers, Goals and Objectives for each of the identified business domains starting with Executive Management. The Executive Management work package contains a Goals tree view, that has captured the primary drivers for the SOA initiative. This view is an artifact that will be gate reviewed at the end of the the preliminary phase, and formally accepted as a baseline at the end of the Vision iteration. However, as stated earlier in this article these models along with several subsequent models are now available for informal stakeholder review and comment.
For now I will use this model to communicate with execute leadership, and members of the executive steering committee to flesh out any uncertainties, ambiguities, missing or unexpressed drivers, or goals. I will also work with executive leadership to ensure that the stated objectives are in line with management expectations. For example, this model can now be used to point out that KPI’s for the stated objectives have not yet been identified. Therefore we have some additional work to capture decisions about the acceptance criteria and commitments before it is ready for baseline an transition to the state of Formally Accepted on the heat map.
My next steps would be to create a series of Goal tree views for each of the business domains, For example, I will also work with the other business segments and leaders, such as Marketing, The Lending Services program sponsor, and the Technology Operations Group (TOG) to ensure that the stated objectives and KPI’s against Goals are captured and reviewed. I should note that these are somewhat informal review sessions where not only can we consider gaps in understanding, but we are also able to set the stage for decisions about the scope and prioritization of objectives for the outcome of a completed ADM. These decisions are then codify in the Architecture Vision. The next step is to produce a couple of Goal tree views in the Enterprise Architecture work package.
Up to this point I have placed a great deal of my focus on Governance. While this capability is perhaps among the most vital. There are several other SOA capabilities that should be considered. I stated in the second article the executive steering committee has determined that a SOA strategy is a key goal for successfully realizing an agile business. In my humble opinion the certainly this qualifies as an open-ended statement. To narrow the focus of the EA effort I will use the same approach as with capturing and vetting business drivers and goals. Referencing the SOA capabilities found in the TOGAF SOA Source Book. I will create a EA Goal tree view with several EA objectives that will be used to deliver several new SOA capabilities.
The TOGAF Source Book states that “from a TOGAF context: capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve.” Using this definition I will add two new models along with a new SOA Governance Process view. First I’ll add a Goals tree view with several new enterprise architecture objectives. I’ll will then use this view of the SOA Development Goals as part of a larger EA planning exercise. In which I will review the new goals and objectives along with their related capabilities with the executive steering committee. Like any other effort to build new capabilities I will use this view as to prioritize, scope and set expectations in terms of what capabilities will be delivered this cycle of the ADM.
Earlier in the article I explained why a heat map does not provide a list of artifacts. Here is a concrete example. In this tree view I have called out a new capability to use six-sigma as a discipline within the BPM practice. In the next iteration I will begin work on the development of the business process views. During that activity I will then introduce the use of six-sigma and the DAMIC methodology for business process analysis. Actually, this decision was made as part of some of the “Light” work done in the ideation/inception iteration, and based in a stakeholders inquiry about development of a BPM practice. As a result this capability will has been identified in the Goal tree view. The new artifact simply appears and can be reviewed or further developed.
Unlock Your Potential with Application Modernization
Application modernization is a growing area of focus for enterprises. If you’re considering this path to cloud adoption, this guide explores considerations for the best approach – cloud native or legacy migration – and more.
This is also a good example of how a capability can be introduce as new discipline along with it’s associated methodology. The takeaway here is that even a new discipline such as six-sigma is still developed within the ADM process. In the next iteration I will introduce value stream analysis as part of this new capability in supporting Portfolio Management. According to the TOGAF this would trigger a new iteration of the ADM. While the development of a BPM practice is outside the scope of this cycle of the ADM, I will touch on the subject in the next article.
For now I’ll return my focus to capturing a few more elements of the preliminary phase. It’s not unusual that business drives, and their related goals and objective are defined outside the formality of the ADM. Such is the case with FYI Bank. Since context is always an important dimension of any project, I will build out a work package view containing several Goals viewpoints.
Perhaps you’re wondering, or maybe not! why I’ve placed the Enterprise Architecture Goals viewpoint as the center of the model. The first reason is the modeling syntax in which Drivers create Goals, while Objectives realizes the Goals, and the deliverable is a demonstrable capability. I think there is a nuance worth noting at this point. The models that are being produced as part of the EA effort is not the architecture. They are simply a means for reasoning and making decisions. Models in this sense are not the deliverables. The deliverable is the capability, and that is the architecture.
The second reason which I feel is an important perspective. Is how the SOA Governance capability is tied to the other enterprise business capabilities. So this context view provides not only a representation of the heterogeneous nature of the enterprise. It also informs me about the business segments that will be involved in the delivery of the the new business capability. Therefore, the Enterprise Architecture work package is at the center because it represent the impact of EA capabilities across the identified business domains in the enterprise.
Starting with this view I’ll will then applying various levels of abstraction beginning with the Executive Management Goals. The Executive initiative view is an artifact that will be eventually part of a gate review at the end of the the preliminary phase. However, as stated earlier in this article these two models along with several subsequent models are now available for informal stakeholder review. And I will use these models to work with members of execute leadership, and the executive steering committee to flesh out any uncertainties, ambiguities, missing or unexpressed drivers, or goals. I will also work with leadership to ensure that the stated objectives are in line with expectations. These particular models will also be used to point out that the KPI’s for the objectives have not yet been identified. Therefore, there are some decisions and commitments that must be addressed before these views are ready for baseline to the state of Formally Accepted on the heat map.
Next I will work with the other business segments, such as Marketing, The Lending Services program sponsor, the Technology Operations Group. These are somewhat informal review sessions where not only can we consider gaps in understanding, but also we stage for prioritization and formation of the Architecture Vision. In addition to the business Goals I will also provide a couple of views from the Enterprise Architecture work package.
Up to this point I have primarily focused on Governance. While this capability is perhaps the most vital, there are several other SOA capabilities to consider. As stated in the second article; the executive steering committee has determined that business agility can be achieved by building a SOA strategy. In my humble opinion this certainly qualifies as an open-ended statement. So to narrow focus I will take the same approach as used when fleshing out the business goals. In the Enterprise Architecture work package I will create an EA Goal tree with several objectives. I’ll then abstract the Goals into a viewpoint and tie in several SOA capabilities that have been taken from the TOGAF SOA Source Book.
The TOGAF Source Book states that “from a TOGAF context: capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve.” Given this definition I will add two new models along with a new SOA Governance Process viewpoint. But first I’ll add the new Goals tree view. I’ll will then use this SOA Development Goals view as an input to an EA planning exercise. Part of the planning will be to review the new goals and their related capabilities with the executive steering committee. This will also provide an opportunity to prioritize, scope and set expectations in terms of what EA capabilities will be delivered this iteration of the ADM.
The next artifact is a result activity to build out a SOA Governance Process. The goal here is to integrate and or align the SOA Governance process in terms of standards, tools, and governance checkpoints with FYI Bank’s Program Portfolio Management Office, as well as with other management frameworks used in the Operations and Solution Delivery business domains. I’ll use a level 1 BPMN process diagram which allows me to include organizations and the required roles. I’ll also use the process model to introduce artifacts such as governance checkpoint documents, as well as identifying potential integration points with current or future technologies such as Lifecycle and Policy Manager Tools. Another advantage of using a BPMN process model is that I can also reason about data processing at the integrations points, which may also provide opportunities for automation.
Some examples are, a Service Definition as an input to the Service Portfolio Management, which I expect will result in an input to the Portfolio Backlog used by Solution Portfolio Management sub-process. A Service metadata message may be an automated input to a Lifecycle Manager system that is supporting the Service Lifecycle Management sub-process. Another example is that I will also be able to reason about interactions between other sub-processes that may require further investigation in terms of what specific information is needed. Such as it is between the Solution Portfolio Management and Solution Lifecycle Management, this is where an Architecture Definition (AD) is realized for Non-functional requirements; in terms of architectural principles, constraints, security, monitoring, and Key Process Indicators. There are also other aspect of the AD that I will cover a little later in the article. In these examples I’m starting at a notional level to consider process around the governance model and how it will be used between organizations, people, as well any technologies that will enable process.
Now I come to the final activities in this article. This will be in the area of some informal work around the Opportunities and Solutions, as well as defining the elements of the Architecture Definition. Before I address the Architecture Definition (AD) artifact, I’d like to look back to the conclusion of second blog article where there are still a couple of things yet to cover in this article. First I have not yet tied principals into the continuum, and then there was the introduction of key business decision to use IBM DataPower Integration Appliances as a strategic technology, which will be added to the Platform Service capability.
To address these concerns I’ll turn to the Architecture Definition. This artifact encompasses the rather complex meta-model that is defined as the SOA Reference Architecture Technical Standard in the TOGAF SOA source book. At the heart of this sophisticated object metamodel is the Architectural Building Block (ABB). The Architecture Definition is intended to serve as the integral component representing the ABB. Perhaps the best way to describe this artifacts is that, it acts as a container in which we instantiate the SOA Reference Architecture. What’s most unique about this artifact is that it is primarily realized as model elements in the EA content repository. Which I will published as supporting Web documents. This object diagram represents the SOA Reference Architecture Technical Standard.
Next I have the AD view. This is an output of the Solution Portfolio Management sub-process. Notice that the AD model has references to the Principles viewpoint work package, which is the catalog of architectural principles. So Principles will now be tied to the Solution Lifecycle Management subprocess. The next reference is to the Technical Reference Model, which is an artifact from the the Technology phase of the ADM, and is a representation of Enabling Technologies. There also a reference to the EA and Project EA Requirements work packages, these contain NFR’s, constraints and assumptions. And finally, there is a reference to a Logical Layer Viewpoint work package. This corresponds to the Layer object, I will go into greater detail in the next section.
The final activity for this article, was to introduce the new platform service capability. For this I will provide the initial logical contextual view, which is the SOA Service Appliance Context View. This is perhaps the first of several logical architecture views. This view represents a logical perspective of the IBM SOA Appliance family in the larger solution context. I’ve provided a high level abstraction of the technical capabilities of the appliance, primarily because the solution architect may have several choices from the IBM product family. Also because I have not added the the business process viewpoints, which will drive some requirements of the solution architecture. This will undoubtedly inform the SOA appliance product selection. This activity is underway, and in the role of the Business architect I’ve also started to perform a value stream analysis as part of a Six-Sigma BPM exercise. The results of that work will be presented in the upcoming blogs.
So lets now turn to the logical context model. Essentially the SOA Service Appliance Context view also represents several objects in the meta-model. Primarily the Layer object, and the capability object which is represented in terms of the technical functionality of the SOA appliance. The Enterprise Platform Service Appliance package is a layer that represents the Solution Building Block object. The Infrastructure Services package is actually contained in the Technical Reference Architecture layer, which means that it is aligned with the Enabling Technologies. The Service Layer which is in the Business Architecture domain represents a capability object. The Business Application layer is a high level abstraction of the Portal solution. The layers within this package will be aligned the the metamodel in a later article. Finally, there is an Enterprise Information Systems layer. This layer represents Enabling Technology, Solution Building Blocks, and Capability objects in the metamodel.
In the next blog, it’s very likely that I will refine some elements in the preliminary phase work packages in preparation of a formal gate review. I will introduce requirements, which has already been an ongoing activity. But the primary focus will be on the architectural vision. Now that I have introduced the heat map this will be a first class artifact for iteration planning. Also if time and space permits, I will introduce some ideas around a larger agile framework in which architectural epics will be presented as an integration with SCRUM like project management methodologies. While this is a bit out of scope, I thinks it is worth consideration. I will also take a deeper dive into the Business, Application, and Technology domains, with an emphasis on the business process and the information model.
For those of you who would like to follow along by viewing the EA Model I have provided the content repository as Web Documents in a ZIP file. NOTE: This is the Content Repository in the early stage of the project. As I move through the iterations I will enrich the model content, and clean up the repository. Click-Here – FYI Bank EA Model
