The Open Group and Enterprise Architecture

Steven Nunn from the Open Group, an enterprise architecture framework and certification body, weighs in on the theory and practice of enterprise architecture.

Enterprise architecture (EA) is a demanding profession that combines skills in hardware and software technology, planning, negotiating, and business. There is no formal academic training program on the subject, and most practitioners spend years on the job honing their technology skills while learning and applying the soft skills essential to success in the EA field. Because of the lack of formal training or professional associations available, most EA professionals have found their career path by hit or miss, with little or no external support.

The Open Group works towards enabling access to integrated information within and between enterprises based on open standards and global interoperability. Starting in the early 1990s, it recognized and promoted EA as a discipline and practice essential in establishing a coherent structure and plan for comprehensive IT support for business goals. Today, the organization develops and promotes TOGAF (The Open Group Architecture Framework), and offer a new certification program for enterprise architects.

To find out more about TOGAF and its EA certification programs, FTPOnline spoke to The Open Group's Steve Nunn. Steve Nunn is vice president and chief operating officer of The Open Group, and has management responsibility for legal, finance, human resources, IT facilities, and facilities issues. A lawyer by training, Steve's primary role is to ensure the legal protection of the assets of The Open Group, particularly its intellectual property. One of his main tasks is the development, maintenance, and policing of The Open Group's trademark portfolio, including the registered trademarks behind The Open Group brand.

Steve has an L.L.B. (Honors) in Law with French and retains a current certification to practice as a solicitor in England and Wales. He joined the company in 1993, having previously been a solicitor in a large commercial law firm that specialized in intellectual property and information technology law.

Q: Steve, how would you define an enterprise architect? Who is this person?

Steve Nunn: There's a great deal of discussion surrounding just what the definition of the enterprise architect is. As you know, we're a member-sponsored group, and our members are having that discussion right now. Right now I would say that the enterprise architect is an IT person who understands the business and is willing and able to bridge that gap. Not many people can speak both languages. It involves application architecture and data architecture, and how they fit in. Are you familiar with the city planner model of enterprise architecture?

Q: We've heard talks on the subject.

Nunn: So basically, an enterprise architect would go about planning much like the city planner, who is concerned about basic services such as water and electricity [and] then looks at what type of roads and streets would serve the needs of the city. Based on that infrastructure, the planner would determine what kinds of buildings would be supported and required, and in that manner build a master plan for a city.

Rather than cobble things together, today we have organizations that have been built through mergers or rapid expansions, and have departments and systems within a single enterprise that had never been intended to interact together. Often these interactions fail and are discredited. With proper planning, through the application of an enterprise architecture, they have a better chance of succeeding because you get a much more thought-through requirement-driven approach.

The other aspect that defines an enterprise architect is the ability to communicate well across an organization. That's fairly essential within the technical and business communities, right up to the board level. With my background as an attorney, I understand that professions and organizations have a language all their own. The ability to speak to people in their language, and address their needs and concerns, is a big part of being an enterprise architect. The goal is to align IT with the business drivers of the goals of the organization.

Q: What circumstances within the business have created this need for an enterprise architect practice?

Nunn: A bunch of different things. One is the idea of the need for boundaryless information flow. Information needs to flow between departments within an organization and between organizations. There is a need to get systems talking with each other and to have common elements of systems. This is an increasingly important part of business and has the potential to continue being a differentiator between organizations. I also think that departments and their systems have grown up silos—the manufacturing department, the finance department, were designed and implemented to serve their individual needs. The need for all of that information to be available to anyone in the organization is one important thing driving enterprise architecture.

In addition, with mergers and acquisitions requiring the bringing of systems together is another job entirely. Plus, I think the change in ways some of the businesses transacted in the field, with mobile users out in the field, seeing real customer requirements, and having requirements of their own, and having to communicate those requirements and get action on them. The transition to this model cries out for someone to look at what's going on overall in the business, and to be able to support it from an architectural point of view.

Q: Let's look at The Open Group. You've been around for quite some time. What got you into the practice of enterprise architecture?

Nunn: Well, we are a member-driven group. Fundamentally, it was our belief in the concept of boundaryless information flow. There are boundaries that are permeable, and they need to be crossed in ways that are secure and reliable and timely. Enterprise architecture is a key element of that. This kind of model needs architecting from the start. We got into enterprise architecture as a critical element of that. Our members have been working on architecture ideas that manifested themselves as TOGAF for quite some time.

Q: I didn't realize TOGAF had been under development for a long time.

Nunn: Yes, we have a history with TOGAF since 1992 or 1993, and it started as a member activity, with our members saying we need a starting point to begin working on architectures. We had a starting point with DODAF, the Department of Defense Architecture Framework, but since then we've developed it independently. And ever since then we have been building TOGAF, to version 8.1.1 today, and we have members working on TOGAF 9.

Thanks to our members, we recognized the need for an enterprise architecture program early on, and with the ITAC (Information Technology Architect Certification) program.

Q: Now, you're not trying to standardized enterprise architecture so much as you are trying to establish the framework and certify professionals in that framework.

Nunn: That's absolutely right. We're not in any way trying to standardize the architecture itself. What TOGAF has is an ADM, an Architect's Development Method, that helps define the phases to the architecture process. That is very popular, and has been widely downloaded and used to help with enterprise architecture needs. TOGAF helped us get into other areas in enterprise architecture, with a broader focus, and has enabled the industry to encourage us to devise an architecture certification process, and that's what ITAC is.

TOGAF certification is how well you know TOGAF and can implement it. ITAC is an overall skills and experience program that involves an application putting together a portfolio of experiences in architecture, and then [it is reviewed] by a board of three other architects. The board determines if the application has the requisite levels of experience and knowledge specified by ITAC. There are different levels to the program, and the current one emphasizes current practice. Because we are a neutral third party, we believe that our certification will be much more widely sought and credible than those that focus on company-specific technologies.

Q: Since you bring up certification, can you tell us, in a general sense, what an architect needs to know to be successful in an enterprise?

Q: There's a lot of detail available on our that on our Web site. However, at a high level, the person has to have worked on projects spanning multiple departments or across the organization, either entire projects or significant parts of them. We expect five years of experience doing so, with roles in planning, design, implementation, and communications within the organization. There has to be a sound technical systems background, in understanding how systems work, and knowing at least one architecture methodology or framework. The key is having experience in implementing architectures for real.

Q: Now let's take a person, say with a computer science degree, and a few years of experience working in an enterprise. This person wants to be an enterprise architect. What should they do in order to make this possible?

Nunn: This assumes that individual is working in an organization where it is possible to map out that career path early in the career. Many enterprises haven't developed the maturity to have a formal or established enterprise architect practice. There are other organizations where senior management hasn't been properly introduced to the concept. Assuming that these hurdles have been crossed, however, there are few who have started out as enterprise architects.

But if there is someone who has the technical education and a few years of IT experience, it is a matter of that person talking the language of enterprise architects, and taking an enterprise architecture approach to projects. If there aren't many enterprise architects in the organization, they can bring the enterprise architecture frameworks into the organization.

If the person is in a large organization with an established enterprise architect practice, he or she should seek out the people who are already engaged in that activity. In some cases, that practice may be scattered among different facilities around the world.

Q: So it sounds like having a mentor would be useful.

Nunn: Having a mentor would be very helpful, assuming that such a person exists in the organization. That is an ideal way to bring along a young person as an enterprise architect. We are trying to promote the entire concept of helping to create new enterprise architects by working with academic institutions to try to establish courses or elements of courses that involve the concept and practice. If someone follows that path in college, they come out with credibility of the practice in taking their first job.

Q: You mention TOGAF, DODAF, and other enterprise architecture frameworks. Are these complementary in practice, or would you use one but not another. If so, what are their relative strengths and weaknesses?

Nunn: There are some differences between them, but you can combine them into an approach that works for you. Some are required by the organization to which they belong to use DODAF, for example. We've mapped many of the concepts between the two frameworks, but the devil is in the details. Perhaps the value that TOGAF has is in the ADM, the method that it defines. The other value of TOGAF is that it is being evolved by the practitioners, those who are actually doing enterprise architecture.

Q: Earlier you had mentioned an extension of the enterprise architecture concept that was discussed at your conference last week. Could you elaborate?

Nunn: We had an architect from Marriott who took the city planning concept, and specifically the idea of neighborhoods of the city, and extended that to the concept of a public park and garden. There are probably similar analogies out there, but the idea is to come up with a concept or explanation that makes sense to the senior management of your organization. That is really the important part, that you can communicate the concept of enterprise architecture, and its value to the organization, in a way that people at all levels of an organization can understand.

One way that I've used to explain enterprise architecture is the idea of roads, or highways. In England, highways and high construction is driven by local authorities. In one case, there was a highway being constructed between two localities; and because of a lack of planning and coordination, when the two segments of highways met at the border, they were about twenty-five feet off center. So they had to construct a rotary at that point, for no other purpose but to join the two highway segments.