IBM Destination Z - Group home

Thinking and Acting Like an Architect

By Destination Z posted Mon December 23, 2019 03:42 PM


What would happen if you put a carpenter; an electrician; a heating, ventilation and air conditioning (HVAC) technician; and a concrete specialist into a room and asked them to build a house? Could they do it?

This is the way we often do IT projects: We stock the project team with a variety of really smart technology specialists and maybe a project manager. But who provides the vision? Who determines the design of the project solution? Who makes sure the solution adheres to the standards of the organization? Who talks to the stakeholders to ensure that the requirements—What requirements?—are met?

The person who generally “glues together” an IT project is—or should be—the architect. An IT architect (sometimes referred to as a systems architect) can provide valuable contributions to a project and organization. He or she brings together the team, gains an understanding of the business and technology requirements, provides the vision, leads the solution design and ensures that the final design fulfills the requirements of the project’s sponsors.

The architect guides a project from vision to conclusion. Just as a building architect draws a high-level picture of a building and then creates blueprints of how the building will look and how it will be built, the system architect does the same for IT projects. The building architect engages with “subsystem” architects, such as the electrical system designer, the HVAC designer or the foundation specialist and combines the various pieces into a whole.

But what about mainframe environments? Many companies are discovering that a mainframe architect provides the kinds of “architectural thinking” needed to create and guide mainframe-related projects by using architectural methodologies and expertise and applying mainframe-specific expertise to those projects.

Note the use of the word “thinking.” Architects tend to think differently than technology specialists. They employ “top-down thinking,” where they use their acquired knowledge and wisdom of what works and apply it to create a broad view of a solution. They avoid the “hammer/nail” syndrome, where if all they have is a hammer, every problem is a nail. The architect uses a methodology to guide the solution design process and creates a solution based on business conditions, requirements and a variety of alternatives before reaching a conclusion.

The Process

Let’s look at an example: The marketing organization at Acme Enterprises wants to create a new mobile application that allows its customers to reserve a seat in its sales seminars. The seating reservations are generally done by call center reps who take calls from customers and use a CICS 3270 application to reserve a seat. How do they mobile-enable this application?

A team is assembled and includes the architect, some technical subject-matter experts, a project manager and a representative from the call center. The architect decides to hold a solution design workshop to begin the process.

First, the architect looks at the existing business and IT environment. What's driving this mobile requirement? More revenue? Better customer service? Cost-savings? How much? The architect is trying to get the big picture at this point. He or she is constructing a high-level picture. Requirements come first.

Next, what does the existing environment look like? What infrastructure software is in place? How is the existing application written? What mobile devices do they plan to support? Are there constraints that must be adhered to? What IT standards exist?

After the existing environment is defined and requirements are gathered, then the technology solution options can be explored. What are the advantages and disadvantages of each option? Do they stick to the architectural principles and constraints of the organization? Most importantly: Do they meet the requirements gathered up front?

Then the solution creation begins. The architect looks documents the decisions and, with the input of the team, decides what the proper solution should be. He or she draws up an overview of the target architecture and begins to drill down into the operational implementation that’s needed to make it all work.

(I’ll bet you want to know the solution, don’t you? I’ll leave that to your imagination.)

Thoughtful Conclusions

I make it all sound very simple here. There’s a lot more to building the solution than one architecture workshop. But that one exercise encapsulates the overall process. It may take place over the course of many days/weeks of meetings, debates, documentation and artifact creation, and whatever else it takes to get consensus and come up with a sound design that complies with the organization’s goals, requirements and standards.

That solution design scenario has a hidden component—an architectural methodology. The methodology lets the architect follow a process that prevents things from falling through the cracks. It ensures consistency in design and helps prevent that “hammer/nail” thing. It keeps the architect and solution team from jumping to the conclusion without thinking through the problem. And the methodology encourages architectural thinking, that top-down design process that takes a solution from concept to reality in a measured, thoughtful way.

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