When you're building an application for a very specific purpose --- say, processing a charge to an account -- you know what you need to do and how you need to do it. Your architecture might be straightforward, even simple. In the case of enterprise applications, however, a lot of thought has to go into just that topic -- what you need to do and how you need to do it -- before you can even start coding the first line. In the case of large projects, the person doing this thinking is typically an IT architect. This person is responsible for translating business requirements into software requirements. For small projects, and small businesses, this may be a very straightforward task. In the case of larger enterprises, however, this task can be downright formidable. Fortunately, there is help. The Open Group Architecture Framework, or TOGAF, provides a methodology for analyzing your specific situation and turning that analysis into actionable artifacts.
Enterprise IT architecture is not about enterprise applications, it's about doing IT architecture work at the enterprise level. Many enterprise IT architects are being moved from the the office of the CIO to corporate strategy and planning departments. The enterprise IT architect considers the business and technical architecture of the enterprise, creates a strategic vision, and carries out that vision through implementation. This work is not limited to software, but extends to complete systems thinking in the enterprise. Even a simple application needs to be created, deployed, and governed within the context of the entire enterprise architecture.
Some IBM experts are here to discuss what TOGAF is, and why it's in your best interests to understand it. The Open Group Architecture Framework, as the name suggests, is maintained by The Open Group, an organization dedicated to promulgating open standards in industry. For example, it is The Open Group that maintains the UNIX® standard. This means that if you want to put out an "industry-standard UNIX," you have to be sure it conforms to the specifications maintained by The Open Group.
David Jackson and Andras Szakal, in addition to being certified IT Architects within IBM, have worked extensively as part of The Open Group. David is chairperson of The Open Group Architecture Forum. Andras is chairperson of the IT Architect Certification (ITAC) Working Group, which is responsible for the ITAC standard and represents IBM on the Board of Directors for The Open Group. He put in many years working with The Open Group to develop and gain acceptance of TOGAF. He is currently the Chief Architect for the IBM Federal Software Group.
David and Andras agreed to talk to developerWorks about IT architecture in general and TOGAF in particular.
Understanding the IT architect's place in today's business environment
Before discussing TOGAF, we should clarify a larger issue: the architect's role in software development. Some developers just "dive in and code," but most recognize the need for preplanning. However, many developers don't understand the level at which this architecture work takes place. Often, they are familiar with the idea of planning an application, but planning for the enterprise requires a different -- though complementary -- set of skills.
David compares the enterprise or IT architect with that of a civil architect, who plans cities or builds buildings. "The role of the IT architect is to be able to understand the business problem and the business domain and explain it to the technical people, and to be able to understand the technology domains and explain the technical possibilities to business people. Or in the civil architecture notion, it's the architect who can explain to the purchaser -- the person who is funding a building or city, 'These are the possibilities of how you can build this building.' The architect eventually comes up with the blueprints to give to the builder and says, 'OK, here's what the owners of this building want. Here's the way they want this building built, here are the features they want in this building.' But what makes a good architect? Given the presence of both in the equation, is it more important to be able to understand the business side of the conversation or the technical side? It's a question often debated by David and Andras, who favors the technical side.
"Andras believes that a good architect needs to start out as a developer and have a good background in development and operations before becoming an architect," David says. "I think it's harder to take someone who has a strong foundation and mental construct of an engineer and get them to have the artistic bent and artistic nature that's necessary to become a good architect." Is it possible for a really good engineer to become a really good architect? "Some people can move out of that engineering mindset and become an architect, but they might have a harder time doing it."
Andras responds. "I do believe that even though engineering specialists -- who we're talking about here when we're talking about developers -- are not architects, they are still of great and important value. We understand that the architect role and responsibility is focused on taking the business requirements and value and translating that into the proper solution. My personal opinion is that it is valuable to have someone with IT technology background to fill that role, because their role is essentially as the technical lead of the team."
Given that, technical skills are a must, no matter where an IT architect starts out. "A good building architect needs to know the structural strength of steel before they design in it," David agrees.
So there you have a general definition of the IT architect role. But what, you ask, is TOGAF?
Originally designed as a way to develop the technology architecture for an organization, TOGAF has evolved into a methodology for analyzing the overall business architecture. The first part of TOGAF is a methodology for developing your architecture design, which is called the Architecture Development Method (ADM). It has the following nine basic phases:
- Preliminary phase: Framework and principles. Get everyone on board with the plan.
- Phase A: Architecture vision. Define your scope and vision and map your overall strategy.
- Phase B: Business architecture. Describe your current and target business architectures and determine the gap between them.
- Phase C: Information system architectures. Develop target architectures for your data and applications.
- Phase D: Technology architecture. Create the overall target architecture that you will implement in future phases.
- Phase E: Opportunities and solutions. Develop the overall strategy, determining what you will buy, build or reuse, and how you will implement the architecture described in phase D.
- Phase F: Migration planning. Prioritize projects and develop the migration plan.
- Phase G: Implementation governance. Determine how you will provide oversight to the implementation.
- Phase H: Architecture change management. Monitor the running system for necessary changes and determine whether to start a new cycle, looping back to the preliminary phase.
These phases provide a standardized way of analyzing the enterprise and planning and managing the actual implementation.
The second major part of TOGAF is the Enterprise Continuum. This collection of architectural building blocks and models enable you to not only build your architecture design more easily, but also to eliminate ambiguity when discussing various concepts and items involved in the analysis and implementation -- which can be a problem even between groups within a single organization.
For example, The Open Group manages both TOGAF and the IT Architect Certification program (ITAC), which provides a way for experienced IT architects to obtain an industry standard certification. Because both programs involve IT architecture and both are from the same organization, you might assume that arriving at a common terminology is not a problem. In fact, Andras says it's something The Open Group is working on. He says, "There's a lot of flux about some of the definitions of architecture roles and responsibilities across organizations worldwide."
David says that to help solve this problem, "The Open Group Architecture Forum has adopted a lot of the terminology from the IEEE 1471 2000 specification. Seven or eight important terms are spelled out there, including 'architecture,' 'architectural description,' 'view,' 'viewpoint,' and 'stakeholders.' " The forum has incorporated much of that standard into TOGAF.
A common point of confusion about TOGAF is that it isn't actually an architecture, but rather a framework for designing and describing an architecture. "An architectural framework is, at its essence, a classification system for architectural descriptions," David explains. "In addition, TOGAF is an architectural development method. The method provides the process an architect would deploy to arrive at the descriptive artifacts that would populate an architectural framework."
In other words, instead of helping you describe a particular Service-Oriented Architecture (SOA) system, for example, TOGAF can help you decide whether SOA is right for the project at all. The TOGAF methodology helps the architect distill the project to the point where a decision can be made about whether or not SOA as an architectural style can be best applied to solve the architect's original problem.
If all of this sounds like TOGAF is very much a top-down methodology, you're right. As with all top-down methods, it starts with the big picture and breaks it down into progressively smaller pieces. But TOGAF is intended to be a generic method, one that works with any architecture. What happens when you are using a more bottom-up style, such as SOA, which starts with specific functions and builds them into a larger system?
What happens is the classic discussion of "top-down against bottom-up." It's a debate that pushes one of David's hot buttons.
"I want to tear up every article I read that pits the top-down approach against the bottom-up approach because I strongly believe in their complementary natures. The danger is that if there is not a good substantive top-down process, the architecture value realization won't happen. In other words, what gets built may entirely miss the business purpose for which it was launched. And if there's not good bottom-up, the architecture becomes academic and nothing ever gets built. So both are required. It's a yin-yang thing."
Coming from the technical side, Andras explains the engineers' point of view, which often questions the need for all of this top-down work. "Bottom-up people, such as those who are used to working in the Rational Unified Process (RUP), might start with an Object-Oriented Analysis and Design (OOA&D) point of view and base the architecture on that approach because there's a legacy or an investment there. When we first started talking about architecture, we were really talking about the architecture of applications, of programs instead of the architecture systems or enterprise or business systems we're dealing with now. So TOGAF is very much more focused on the enterprise architecture, the architecture of systems, and how they relate to the business for the requirements of the enterprise."
This dichotomy is the reason David believes so strongly in the complementary natures of the two approaches. "If you look at the 'opportunities and solutions,' 'migration planning,' and 'implementation governance' phases of the TOGAF Architecture Development Method -- that's E, F, and G -- those are really areas where a process such as the RUP builds an architectural description -- which, for all intents and purposes, is the logical equivalent of a building architect's set of blueprints that gets handed to a builder for actual construction. The builder has his own processes for going about actually building something. I would say that the RUP is the classic builder's process and is, therefore, extremely complementary to the architecture and creation development process."
With technology getting pushed up the stack, so to speak, and with business processes themselves becoming targets for enterprise IT, should you expect to see more development, more architects, and more developers? Or is that, perhaps, the wrong question?
Andras responds. "One of the things that's really important from my point of view is an evolving process around enterprise architecture and business architecture. As early as 1996 or so, several folks in IBM had started contributing to the idea of business architecture -- that is, applying architectural concepts to the development of designs that are focused on the development of business processes. These designs can then be passed into the IT domain and the IT structure can be instantiated on top of those requirements. Because SOA is really about taking the business process and instantiating it in the IT infrastructure, now you actually have the technology to support that idea. You can see, more and more, the creation of professionals who are supporting the development of business architectures and enterprise architectures."
Overall, this is a tremendous shift in the way most organizations view the integration of IT with their business -- and a shift in the types of staff necessary to carry it out.
The Architecture Forum, IT Architecture Certification, and TOGAF are all about evolving this definition of business architecture and enterprise architecture and creating artifacts that link to the system's architecture. So it's very likely there will be a plentiful crop of architects in the future; that is, people who understand the business, business processes, and industry requirements and who can translate them into artifacts to define the design and development of the IT infrastructure. So you may even see a situation where you have enterprise architects and business architects working together to create assets that are then handed to outsourcing shops or other individuals who simply translate them into IT infrastructure and then reinstantiate them back into IT operations.
This "reinstantiation" means that the more some things change, the more they will stay the same. "Somebody has to translate these requirements that define the architecture into a physical implementation. There's still no magic around that, and that means that somebody has to do the systems engineering as well. In some cases, it may require some integration and some application development, but because of SOA we're likely to see more of a plug-and-play IT environment in which the application is more dynamically defined. It will also be defined at a higher abstraction level that doesn't require as much programming as we've seen in the past. But overall, I think we'll see fewer and fewer software developers in the enterprise itself, because with a better method of defining the requirements for the IT infrastructure, less effort will be needed on the programming side."
Exploring TOGAF, certification, and the future
For the developer, the trend toward outsourcing, already well underway, means developing the skills of an architect is worth considering. For the IT architect, certification is likely to help prove your usefulness to the enterprise. This is another place TOGAF can help.
As discussed earlier, The Open Group runs two different certification programs. The IT Architect Certification program is an obvious choice, but certification requires years of skill and experience, as well as knowledge, making it a problem for developers just entering the field.
TOGAF provides an "in" for this group; the TOGAF certification process requires you to take a class or a test, but does not require previous experience. As an open standard, TOGAF avoids vendor lock-in that sometimes accompanies professional services. In fact, even organizations that have their own methodologies are starting to discover the advantages of using TOGAF.
As Chief Architect for the IBM Federal Software Group, Andras has seen this change first hand. "IBM Global Services has a standard methodology that we use internally, called GS Method. In most cases, the consulting team uses that methodology as the primary method for providing consulting services; when customers require it as part of an outsourcing agreement or contract, obviously we use the methodology they choose. One methodology we have seen become more popular in IGS and other customer-facing activities is TOGAF. More recently within the last year, quite a few practices and IGS have started using TOGAF because their customers or clientele have been requiring it."
TOGAF is important for the enterprise IT architect for one simple reason: It's needed. Large organizations can no longer afford to create isolated applications that perform single functions and don't communicate with other applications. Nor can they ignore the effect that actual business conditions have on their technology requirements. Enterprise architecture is stepping in to provide the link between a business and its technology infrastructure, and TOGAF provides a standard way, using best practices, to enable that link. Architects and developers who want to be architects can leverage TOGAF now, making themselves more effective and more useful in industry both today and in the future.
David Jackson is a consulting IT Architect with IBM Sales and Distribution Division, and has been a certified IT architect since early 2001. In his current role, David is responsible for all credentialing programs in the Americas. He's been active both inside IBM, participating on architecture certification boards, and outside, working with external standards bodies, such as the Open Group. Recently he has started to do some work with the Object Management Group (OMG) -- the CORBA and IIOP people -- in the area of Service-Oriented Architecture (SOA). He is chairperson for the Open Group Architecture Forum and participates in a joint working group between OMG and the Open Group on TOGAF. For four years, he worked on the IT Architecture Certification (ITAC) before passing it on to Andras Szakal.
Andras Szakal is the Chief Architect for the IBM Federal Software Group, leading software architects across the government space. He's an IBM Distinguished Engineer and a certified Software IT Architect. He represents IBM on the Board of Directors for the Open Group, and is chairperson of the IT Architect Certification Working Group, which is responsible for the ITAC standard. He also works in the Global Enterprise Services forum, which is the primary mechanism for the federal government to work with vendors through the Open Group, and is involved in managing federal government standards.
- Participate in the discussion forum.
-
Examine the TOGAF 8.1 specification, from The Open Group.
-
Find out how to get TOGAF Certified.
-
For information about The Open Group IT Architect Certification program and it's announcement, a press release is available www.opengroup.org/itac/ and www.opengroup.org/press/19jul05-itac.htm.
-
Learn more about SOA in the developerWorks SOA and Web Services zone.
Nicholas Chase has been involved in Web site development for companies such as Lucent Technologies, Sun Microsystems, Oracle, and the Tampa Bay Buccaneers. Nick has been a high school physics teacher, a low-level radioactive waste facility manager, an online science fiction magazine editor, a multimedia engineer, an Oracle instructor, and the chief technology officer of an interactive communications company. He is the author of several books, including XML Primer Plus (Sams).
