Todd Biske: Outside the Box

I’m listening to Dana Gardner’s SOA Insights podcast here at the airport. This episode is a discussion with The Open Group about their Enterprise Architect certification. One of the initial questions was whether the role of the SOA Architect was any different from the role of the Enterprise Architect. It seemed that the group in the discussion all agreed that an SOA Architect was a subset of the overall Enterprise Architect role. What did surprise me, however, was the debate on what the responsibilities of the SOA Architect are.

In retrospect, I shouldn’t have been surprised as the same debate is prevalent in Enterprise Architecture as a whole. I’ve worked with organizations whose view on Enterprise Architecture was that it was strictly a technology play, focusing on standard infrastructure. In the SOA space, this is concerned with connectivity between consumers and providers, dealing with the nebulous world of the enterprise service bus, SOA appliances, web services management systems, etc. as well as the technology used to build and execute services, including application servers, orchestration engines, and the like. While less common (but certainly not uncommon), I’ve also encountered organizations where Enterprise Architecture was much closer to the business, including tasks such as business process modeling. Here, it’s much more about the application of technology, rather than the technology itself. Once again, looking at this from the SOA space, the focus would be on the services themselves, not necessarily on the technology used to expose them. What’s my opinion? Simple, it’s both. The only debate is on what is the appropriate organizational structure is for these roles and responsibilities. There’s always some subdivision of responsibilities across multiple people. A topic such as middleware technologies has enterprise applicability but sufficient breadth within it given the continuing evolution of development technologies such that you can have a full time architect focused on the strategy around it.

Regarding whether EA should also include the application of the technology, this was a nice lead in to a second point of debate, which was whether a developer background or a business analyst background leads to an EA career path. Again, I think the right answer is both. A business analyst background will pay significant dividends toward the component of EA concerned with the application of technology, although it depends on how much your analysts participate directly in the technology application efforts. While I do think there’s more potential for some with a technical background to become an EA, simply because of the breadth of solutions to which technologies like Java EE or .NET can be applied, there’s far more value in combining that with business knowledge. Furthermore, the further you go on the business side, the more likely that the role of strategic planner for the business is already being covered by someone on the business side. Those people need to be actively working with EA.

The final point of discussion was around the role of education in Enterprise Architecture. The panelists all agreed that experience was a critical factor, and that you can’t teach experience, however there are aspects that can be taught. One panelist gave the example of a course on TOGAF. The one subject that didn’t come up in this or the discussion around the career path to EA was the ability to be a big picture thinker. For me, this is a must have for anyone in the EA role. Enterprise architecture is about the enterprise. If you can’t see the forest for the trees, you’re going to struggle. If you look at the typical IT organization, what’s the percentage of people who are working on project efforts that are narrowly defined? I’d argue that it is well over 50%. Take out the support and overhead activities, and you’re not left with much. Therefore, EA has to fill that strategic planning gap. You need to be comfortable in working in areas where boundaries are fuzzy, if they’re even known at all. Conflicting priorities and politics are the norm. Personally, I think being a big picture thinker is extremely difficult to teach. I think people naturally prefer to focus on either the details or the bigger picture. I focus on the big picture. As an example, my wife and I are redecorating our front room. She painted everything, and then went out and bought a bunch of artwork for it. She and her mother were hanging the artwork and she asked me to come up and offer my opinion on whether the piano should be moved six inches to the left or not. I told her that it all depended on where the artwork was going to be placed and the balance of the room. I couldn’t offer an opinion solely on the piano, I could only offer an opinion whether considering the entire room. I think I even said that moving the piano six inches was insignificant. Someone who is detail oriented probably would have obsessed over those six inches.

There are risks associated with being a big picture thinker, and it’s important that your EA staff recognize it. Strategy is useless unless you execute. This doesn’t necessarily mean going deep into the details, but it does mean that you need to come up with a logical sequence of activities that can realize the strategy. With each activity, however, you’re narrowing the scope so that you can now leverage the other 90% of the organization that is focused on refining scope and making it happen.

4 Responses to “Role of the Enterprise Architect”