SOA Demands Broader Skills and Experience for Enterprise Architects Across Technical and Political Domains, Says Open Group Panel

Transcript of BriefingsDirect podcast recorded at the 19th Annual Open Group Enterprise Architect's Practitioners Conference on July 22, 2008, in Chicago.

Listen to the podcast. Listen on iTunes/iPod. Sponsor: The Open Group.

Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you're listening to BriefingsDirect. Today, a sponsored podcast discussion coming to you from a live panel at the 19th Annual Open Group Enterprise Architect's Practitioners Conference on July 22, 2008, in Chicago. We're going to discuss the role and impact of skills and experience for Enterprise Architects (EAs) in the context of services-oriented architecture (SOA).

We're going to talk about both the public sector, that is to say, government organizations, as well as the private sector, because these issues cut across all areas of information technology (IT).

First, let me introduce our panel of experts and guests. We are joined by Tony Baer, a senior analyst at Ovum. We're also joined by Eric Knorr, editor-in-chief of InfoWorld, as well as Joe McKendrick, author, consultant, prolific blogger, and IT industry analyst. Andras Szakal, the chief architect at IBM's Federal Software Group is here. And lastly, David Cotterill joins us. He’s head of innovation at the U.K. Government Department for Work and Pensions, which is generally equivalent to the Social Security Administration here in the United States.

We've heard a lot at this conference about the role of enterprise architects, how it's swiftly evolving. There is a need for alignment between business and IT at multiple levels. There is also concern about security and managing complexity as organizations move toward SOA methods and principles.

But when I talk to developers, architects and operations people -- and when we get down to what makes them successful -- they often come back to hiring. They talk about the people that they need to bring into their organizations to succeed, and the correct way to promote and encourage those people within their organizations.

A lot of that, of course, is important to The Open Group and The Open Group Architecture Framework (TOGAF), as well as its certification processes, IT Architect Certification (ITAC). It seems important for us to discuss why certification and frameworks need to take into account the full architect, the full person, not only in terms of their knowledge -- their book knowledge, their a priori knowledge -- but also their experience and skills.

We're asking so much of these people, in the context of politics, collaboration, and transformation. My first question then goes to Andras at IBM. Are the skill sets for EA and for SOA the same, or are they significantly different?

Andras Szakal: That's a good question. I believe that they are significantly different. Obviously, an enterprise architect needs to have a background in an EA method. They have to be able to apply the EA method. There are a whole set of governance requirements that an enterprise architect is involved with that an SOA practitioner may not be involved with.

There is quite a bit of intersection between the SOA architect and the implementation of the business processes that they are responsible for. So that's the intersection between EA and SOA. Certainly, they're not equivalent -- even if you believe some of the media out there.

Some of the SOA advertisements suggest that maybe SOA is equivalent to EA, but it's not. For SOA you need to have a background in understanding how to transform the business processes into actual implementation, versus enterprise architects who are following the EA methods and following the practices for producing the deliverables that are handed over to the EA practitioner.

Gardner: Is there a general rule of thumb about the balance? Is this an 80-20 equation, 60-40, 50-50? From your experience in the government organizations, what's the proper balance, when you're hiring an architect, between being technically savvy, and the other skills around organization and management?

Szakal: Within the government, EA is, I would say, trending more toward the political aspect, to the executive-level practitioner, than it is, say, an integrator who has hired a set of well-trained SOA practitioners.

The enterprise architect is really more focused on trying to bring the organization together around a business strategy or mission. And, certainly, they understand the tooling and how to translate the mission, vision, and strategy into an SOA architecture -- at least in the government. If you look at folks like some of the past enterprise architects and chief architects, like Dick Burk [former Chief Architect and Manager, Federal Enterprise Architecture Program Office of E-Government and Information Technology Office of Management and Budget, Executive Office of the U.S. President] … I would say he was more of an administrator than a practitioner.

If you look at the SOA practitioners who come from the systems integrators, who are the majority of the individuals who implement systems in the U.S. federal government's base, they are focused more on IT and the implementation.

Gardner: Good, thanks. David Cotterill, in the U.K. you are a very large and substantial agency. How do you view this balancing act between the skills and knowledge? Is this about book skills? Is it about experience?

Of course, we are dealing with the most variable of variables -- people. How are you seeing the breakdown and where do you see the most important skill sets for “new age,” if you will, enterprise architects?

David Cotterill: Well, I think the technical background can be taken as a given for an enterprise architect. We expect that they have a certain level of depth and breadth about them, in terms of the broadest kind of technology platforms. But what we are really looking for are people who can then move into the business space, who have a lot more of the softer skills, things like influencing … How do you build and maintain a relationship with a senior business executive?

Those are kind of the skills sets that we're looking for, and they are hard to find. Typically, you find them in consultants who charge you a lot of money. But they're also skills that can be learned -- provided you have a certain level of experience.

We try to find people who have a good solid technical background and who show the aptitude for being able to develop those softer skills. Then, we place them in an environment and give them the challenge to actually develop those skills and maintain those relationships with the business. When it works, it's a really great thing, because they can become the trusted partner of our business people and unmask all the difficulties of the IT that lies behind.

We also have a more applications-focused space, in terms of a delivery-focused space. We need people who have a greater, more technical understanding of what the IT would be from our perspective, so that they can challenge the integrators and the suppliers -- just to make sure that they are doing the right thing, that we're keeping as open and flexible as we would like to be, and so that we're not tied into any given supplier.

Gardner: A lot of these roles are new and they're unexplored. We are into new territory. What do you look for in terms of the right kind of experience, the right mix of experience, for the people that you want to bring into these roles?

Cotterill: We hire a lot of people from financial services, because working with an organization the size of ours, you have to not be fazed by the scale of what you are trying to do. So, it helps having worked in a large organization, and understanding the complexities of scale. Typically, we're looking for people who have presented at a board level before, so they have demonstrated the ability to engage with board-level executives. That's really what we're trying to get.

Gardner: Let's go to some of our analysts. Tony Baer, you've been covering SOA for some time. We often hear a lot of prescriptives and definitions, methodologies, reference implementations and so forth -- and not a lot of attention is given to this dynamic management at the human level. Do the software vendors need to come out with a different messaging approach to help these organizations as they try to transform themselves, not just in terms of product, but in terms of this business-IT alignment?

Tony Baer: The short answer is “yes,” but the long answer is that vendors are having an awfully hard time trying to bridge the gap. I'll just give an example of IBM. I'm not trying to single out IBM here. IBM has probably been one of the companies that been most honest about this.

Just to give an idea in terms of trying to bridge different silos, I was talking with Danny Sabbah at IBM’s Rational division, and one of the interesting results of IBM's acquisition of Rational was that they have tried to cross-purpose some of the assets from Rational, where it could apply to some of the other product groups.

The obvious place is in the area of concern over how your systems operate at runtime. So they applied elements of the Rational Unified Process to Tivoli, but they also found at the same time that each brand was used to marketing to different entry points within the organization. They had a hard time trying to bridge that, because there was a mutual distrust.

As I said, I'm not singling out IBM here. I think IBM has been more ambitious in trying to tackle this problem, more honest about it. The same thing here applies with SOA and EA, and with trying to define and hopefully raise the consciousness within the EA profession that you need to have more of a business-level sensibility.

So the short of it is, the answer is yes. The long of it is, it's going to be awfully difficult to get there.

Gardner: Well, let's go to IBM for a second and give them a chance. I'm sure that within their own organization they are also dealing with, "Which came first, the chicken or the egg," except it's professional services or software, and you have mentioned, Andras, that you have this discussion. It's a tough problem.

Szakal: When we are engaging with the customer, we try to have one face. It depends on the business problem that they are solving. So, do you have a discussion about how you implement SOA, or do you first kind of try to roll back the discussion to the point where you can say, "What is the business problem?" and then apply some kind of framework and methodology to mete that out effectively, and then begin to map on the technologies that are necessary to be there.

That's the balance my group tries to play. We are software architects, but we are really trying to solve the business problem. We do this through a framework that we call the SOA Entry Points. We call this people, process, information, connectivity, and reuse. We apply a framework we now call the Smart SOA Approach, which allows you to try to define where you are on the continuum of maturity, and how you apply that with respect to the needs of the business and the business function that you are implementing. An organization that is essentially immature will want to begin to implement SOA infrastructure before they begin to integrate business processes or dynamically adopt SOA at very higher maturity rate.

Gardner: I would also like to bounce a question off of you, Andras. When you're hiring, what do you look for in the requirements? Is there any surprise for this audience about what you look for on the resume of the people that you like to bring into be architects for you at IBM?

Szakal: That's a good question, because I do hire quite a few architects. I would look for people who have deep technical skills, and have had experience in implementing systems successfully. I have seen plenty of database administrators come to me and try to call themselves an architect, and you can't be one-dimensional on the information side, although I am an information bigot too.

So you're looking for a broad experience and somebody who has methodology background in design, but also in enterprise architecture. In that way, they can go from understanding the role of the enterprise architect, and how you take the business problem and slice that out into business processes, and then map the technology layer on to it.

Gardner: Are there any things that you might see on a resume that would disqualify someone in your mind from this role of modern-day enterprise architect focusing more on SOA?

Szakal: I think there are few that would disqualify. You have to be very articulate, both written and verbally. Obviously, you cannot work with people if you have no people skills. You have to have a broad background in technology, both hardware and software. You have to understand the value of EA and business-process choreography. So if you are simply a database administrator and you are very focused on design, that's not really architecture.

If you are simply one-dimensional, the architecture that you are applying is the architecture that you know, and you are not really acting as an “architect.” If you only implemented an IBM solution, a DB2 solution, or say a Microsoft .NET solution, are you really an architect -- or are you just somebody who is a very good specialist at implementing .NET or an information management solution?

Gardner: Joe McKendrick, it sounds like we are defining a newer super-human role here for someone. Not too stuck in one aspect of their IT experience, but not overly technical either. They need to be a politician, a chef, a gardener, and a house painter. It sounds like a difficult thing for any one person to step up to. Is this all feasible? Is this logical? Should we certify individuals, or is this really something that probably requires more of a team?

Joe McKendrick: Thanks, Dana. It's a great point, and I want to take it back it to your previous question about how the vendors are addressing this. IBM is a kind of an exception to the rule here, but what we are seeing in the industry is that the vendors are talking very actively about business transformation, which is a very high-level activity. Ultimately, the goal of SOA is a fairly major transformation of the business to achieve more agility and more flexibility. However, most of the vendor community targets the IT department from the CIO on down.

The big question is whether the vendor community, at this stage in the game, may be asking a little too much of IT departments. Do IT personnel, IT managers, really have the bandwidth or the training, the wherewithal, or the organizational support to go out to the rest of the organization, and say, "Okay, folks, we are going to transform you now." I think our leading IT vendors, in particular, are leaning a little bit too heavily on their IT department, where SOA is a community effort.

In fact, the analogy I'd like to think of in terms of SOA is a condominium association. If you look at a condo association, you don't have one single owner. You have multiple owners. No one really has complete ownership of the building or the community. What happens is that each owner turns over management of the community to this governance group, the condo management association. IT is one of those owners. The condo turns shared services, be it gardening, landscaping, trash pick up and so forth to the management association.

Gardner: Well, I have to say, I hope that the IT department work a little better than some of the condo associations I have been affiliated with. That brings up another issue, and so let's go to Eric Knorr from InfoWorld. This sounds like balancing on so many different levels … group versus individual, command-and-control versus collaboration.

It reminds me of what's taking place in development on the design-time side of things around, Agile and Scrum. I know that Agile and Scrum might not be germane to an architect, but they have been designed to deal with teams and complexity and managing many moving parts by creating more of a team approach with a leader, sometimes called a master, and lots of iterative-stage meetings. Does this make sense, talking about not so much an individual or a team, but really a new way to manage complexity and innovation in a fast-paced environment?

Eric Knorr: Within the context of SOA, one thing we might not have touched on yet is that often, at least in the most successful examples that we have seen, there has to be some sort of visionary leadership. In case study after case study, you run into a chief architect, or even a chief technology officer sometimes, who has really made that connection, in an SOA context, between not only looking at the business processes, but breaking them down into business services and figuring out how to map a technical infrastructure against that.

That leadership is so important, because SOA is such an elusive concept that it's very easy to fall back into the old habits of enterprise application integration (EAI), and thinking in terms of point-to-point integration and not thinking in terms about the last presentation, that strategic value.

At the same time, SOA doesn't happen by decree. It happens with a feedback loop from the bottom up. The demands on the leadership skills are really very high. In organizing these teams that you are talking about here, a board of review is an essential part of that. Maybe you start your governance with an interoperability framework, so everybody knows what protocols are being used.

Then, you get deeper into the design-time governance rules, and you don't want to get to a point where you have such a granular level of rules that your best developers feel like they are being strangled … "Oh, here come the governance cops." So, you need to have that sort of reality feedback, and I think that takes a high level of managerial skill to pull off and still keep everybody on the same track, because if you don't exert enough control, you are going to have people building redundant services again. It's a real balancing act.

Gardner: I suppose it often happens, both in development and in IT operations, that dictates will come down, methodologies will be established, lists will be made, matrices will be presented, people will nod their heads, and they'll go off and do whatever they think it takes to get the job done, which gives us a little bit of a problem in terms of maintaining security, and maintaining the expectations and requirements to the business side of the house. Let's go back to David Cotterill. In the real world, in your organization, do you find that people often ignore what becomes the supposed standards of operating procedure?

Cotterill: Not that often, actually, because in the U.K. we've had some recent examples of where people have ignored operating procedures around security, and the message is pretty clear now that we've put in a lot of governance and compliance procedures to try and remove that level of, "I am just going to ignore and do what I feel is right. I'll publish something which I feel is the right thing to do."

We know that the impacts of that are not IT impacts, but they affect the business, the organization, and they affect ministers. Our friends in the press like to get hold of those things. So, we are very, very sensitive to not allowing that kind of “skunkworks” kind of thing to see the light of day.

The challenge, therefore is -- and this goes back to think to the point about visionary leadership -- how do you establish the right governance and platforms that allow people to be innovative in terms of the solutions that they bring forward, but also has that right level of control that says, "Okay, you are not going to publish something which opens up the entire department's customer information to attack." It's a real balancing act, and that's where leadership comes in I think.

Gardner: I am assuming that the Information Technology Infrastructure Library (ITIL) plays a significant role in your organization?

Cotterill: Absolutely, in terms of the operations management.

Gardner: And with ITIL, this moves you toward the shared services approach of IT management, the understanding that the users in your business at large or, in your case, the government department, are the real customers. Perhaps market forces come into play. That is to say, supply and demand. You don't get paid if the bids don't come in. The bids don't come in if the experience isn't good and rewarding over time for the end users. Do you think that whenever we deal with complexity, on the level of we are talking about, that supply and demand, letting the free forces of competition come into play -- does that help?

Cotterill: I think it helps. Government traditionally has a very command-and-control approach to innovation, and that stifles innovation effectively. I know it's a most effective method of stifling innovation. So when working with suppliers what we are always trying to do is introduce that level of competition. It's not necessarily just a vendor-customer relationship that we are talking about, because we are dealing with services that affect citizens and public information that should be available to citizens. We actually have to look about how the citizens want to use the information that government holds.

As an example, in the U.K. recently the government just launched a competition called "Show Us A Better Way," which is open to the public to identify uses of U.K. government data. How would they like to see U.K. government data mashed up to present new innovative solutions for the public? That's kind of an interesting thing, which takes us out that traditional supplier customer model.

Gardner: Okay, I'd like to check one of my own premises, and that was that SOA and enterprise architecture is common and similar between large enterprises and the public sector. Let's go to Andras at IBM. Do you find that to be the case from your experience that the way that you are dealing with your federal and government clientele gives you certain advantages or differentiates you from what is going on in the private sector?

Szakal: Obviously, within the U.S. federal government space, EA was adopted as an industry, before many other industries using failure modes and effects analysis (FMEA) and the Department of Defense Architecture Framework (DoDAF). IBM is very focused on trying to create a normative model for enterprise architecture.

We started off doing that with DoDAF in the Object Management Group (OMG), and now we've kind of settled on Unified Modeling Language (UML), the next innovative version of that standard which establishes a normative metamodel. You can actually flow artifacts from the EA into the actual IT architecture and design layer, so that there is seamless integration. We can have tool-based round tripping, so that we can actually have a dynamic asset management repository that is pulled in dynamically at the lowest levels into the EA layer that we can then use as part of our normative models.

Then we can push that down into the design layer, and it all connects and makes sense. We can make sure that there is a normalization of the artifacts and not just pretty pictures at the A level being handed over to an IT architect, who then has a process of going through and making their own determinations about the meaning of that picture. Those are some of the challenges that we face as a community.

Gardner: Well, I think clearly what we've heard form our panelists aligns well with many of the discussions today -- how transparency and breaking out of silos is important, not just for technology, but for how people behave in, and operate, and in understanding the business goals, and communicating them appropriately.

Even as many moving parts become essential, it is indeed a talented person who can cross the boundaries of the technology issues, and foster this collaboration clearly by an evangelism, across not only technology, but the business domains. I certainly congratulate those of you who are doing that, and hope that we can find a lot more folks in the field that are willing to step up and take on such a large responsibility.

I'd like to thank our panel of guests as we close today. We've been joined by Tony Baer, senior analyst at Ovum; Eric Knorr, editor-in-chief at InfoWorld; Joe McKendrick author and IT analyst and blogger; Andras Szakal, chief architect, IBM's Federal Software Group; and David Cotterill, head of innovation -- a good title, if you can manage to get it -- at the U.K. Government Department for Work and Pensions.

This is Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. I'd like to thank Allen Brown and The Open Group for helping put this together. Thanks, and have a good day.

Listen to the podcast. Listen on iTunes/iPod. Sponsor: The Open Group.

Transcript of BriefingsDirect podcast recorded at the 19th Annual Open Group Enterprise Architect's Practitioners Conference on July 22, 2008, in Chicago.