Print Email

Architects and Methodologies

Put your method where your mind is

11/11/2015 12:30:44 AM | In my last article on architecture, I talked about architectural thinking and wrote a bit on how architects must think in a top-down manner and tackle problems starting with what the “as-is” environment looks like, then looking at requirements and letting those factors drive potential solutions. That’s a pretty high-level thought process. The challenge is ensuring that an architect does this consistently and makes sure nothing gets missed.

That kind of rigor in an architect’s behavior is normally driven by the use of an architectural methodology. A methodology is a “codification” of how the architect thinks. It links overt behavior with architectural thinking.

Frameworks to Build Solutions

There are a couple of ways an architect can use a methodology or framework to build architectures and solutions. First, architects produce architectures. An architecture framework/methodology is helpful to provide a path to producing an architecture. There are a number of architectural frameworks out there, the most commonly known being The Open Group’s “The Open Group Architecture Forum,” (TOGAF) and the Zachman Framework. There are others. One can embark on some pretty esoteric discussions on what each of these are all about. You can read more about these and other frameworks and architecture taxonomies in this Roger Sessions article [[LINK: ]] from 2007. But in general, both Zachman and TOGAF help an enterprise architect develop architectures based on a consistent, enterprise-wide framework. The architectures built with these frameworks are generally higher-level definitions representing how business and IT interacts.

Architects also use those architectures to guide their creation of solution designs. There have been many intellectual debates about design versus architecture. A key difference between the two is the depth of abstraction. An architecture tends to be a somewhat abstract depiction of a system. The architect develops a set of artifacts that represent the architecture from a high level and documents various levels of detail. A solution design is more of a concrete instantiation of the architecture at the lowest level of detail. The solution design starts with the conceptual view of the architecture and draws the detailed blueprint of how to do the construction.

An example of that conceptual architectural representation is IBM’s Cloud Computing Reference Architecture (CCRA). Figure 1 shows how the CCRA provides high-level guidance on how a customer might implement cloud solutions. This is an Architectural Overview diagram, certainly not the sum total of the CCRA, but it’s an example of one of the artifacts that is created during the architectural design process. The CCRA can provide an architect with the general guidance on how to establish a cloud computing infrastructure. The solution designer would use that reference architecture to guide the creation of a specific design using the CCRA’s assets.

Figure 1: IBM CCRA Overview

Solution Design Methodologies

IBM architects use a variety of solution design methodologies to direct activities during the solution design process. The Open Group architect certification process requires that an architect is knowledgeable in multiple solution design methodologies. The Open Group website lists a number of methods that they recognize. One of those methodologies, created by IBM, is known as Team Solution Design. This methodology documents a number of phases, activities and tasks within the phases that are key to designing an IT solution. Each task has a recommended input and output, which are the work products and related artifacts that document the work done during that task. In some cases, one work product will have a dependency upon other work products for completion.

Using Team Solution Design or any other solution design methodology can keep the architect on the proper track. The method doesn’t need to be followed precisely and each activity/task defined within the methodology doesn’t have to be executed in every design engagement. Sometimes the design problem or the customer situation doesn’t require the kind of rigor that would come from using the methodology end-to-end.

Some tasks that are a part of the Team Solution Design methodology include to:

  • Understand the business environment and objectives
  • Define the project
  • Describe the system context
  • Document architectural decisions
  • Develop architectural overview
There are many others not listed here, but that last one—the architectural overview—is notable. There’s a temptation to jump straight to the solution architecture when a technical consultant believes they already know the answer to a problem. This is the “draw it on a napkin” syndrome. Sometimes the solution team may start designing (on a napkin, whiteboard or any convenient place to draw pictures) without doing the initial legwork of gathering requirements and considering the needs of the users. That often leads to an incomplete or, at best, a sub-optimal solution design. A design methodology like Team Solution Design ensures that the architect has done a complete, end-to-end assessment of the problem and reduces the risk of missing a key aspect of the solution.

The design methodology should not become a bottleneck, though. “Muscle memory” kicks in eventually and the architect knows from experience what comes next. But even for experienced architects, using the phases/activities/tasks of a defined solution design process is like an insurance policy. When an architect is exercising architectural thinking, their brain guides them almost intuitively, but the methodology is the formalized sanity check.

The use of solution design and architectural methodologies is the sign of a mature architect. Methodologies ensure that the appropriate “top-down” thinking is taking place. It also provides a common base of communication across a project team and between multiple architects. Methodology is a means of formalizing architectural thinking into a more concrete, tangible process and set of deliverables. It puts your method where your mind (thinking) is.

Bill Seubert is the North America z Systems Architect Leader for IBM and an Open Group Certified Master Architect.

Please sign in to comment.

Sign In

Join Now!
Big Data Demands Big Iron Skills

Big Data Demands Big Iron Skills

The effects of a mass exodus from the mainframe ranks could affect a number of computing trends, not the least of which is big data.

Read more »

Best System Programmer Attributes

Best System Programmer Attributes

Mainframers give advice and lessons learned on what helps in the real world.

Read more »