Architects working on service-oriented architecture (SOA) implementations need communications skills that they won't find in an engineering textbook, says Michael R. Rollings, senior analyst in the Executive Advisory Program (EAP) at Burton Group.
That is one of the main points in a paper he published this week, "Enterprise Architecture is More than Engineering". While the paper focuses on the enterprise architect, the SOA architect needs the same business and communications skills to succeed, Rollings said in an interview with SearchSOA.com.
Enterprise and SOA architects can fail to achieve their goals in an organization even though they have mastered all the engineering and technical skills, he said. They need a firm grasp of communications, and he doesn't mean IT communications or understanding messaging middleware. He is talking about people communications.
If an architect is failing to achieve goals, it is important to start communicating with business people and listening to what their goals are, Rollings said.
"The first thing is being focused on results," he said. "Look at why you are not achieving those results. Try to understand other people's perceptions of enterprise architecture."
He urges architects to come down out of their isolated ivory tower where they are working on grand designs and find out what other people in the company think of architecture and what it might mean to them. Rollings acknowledge that this type of communications is not easy to do.
"The hardest thing to get across when you're focused on developing different aspects of a technology is to step back and consider different perspective as part of what you're doing," he said.
This might include looking at requirements, business functions and processes from the point of view of other people in the company.
"That will help improve the level of design around the services that you're creating," the Burton analyst said.
He stresses the importance of understanding how business processes are viewed and carried out by other people from other departments or areas within an organization. The architect can then incorporate that into an SOA design that will better meet the business needs.
Having a broader knowledge of how business people view business processes will help the architect who is trying to champion SOA in the enterprise, Rollings said.
"If you are responsible at a higher level to try to sell SOA to the business, I would say turn that around and look for the business outcomes that are required by the business, and the business capabilities that need to be enabled strategically and most urgently," the analyst advised. "Align what you're doing to that. Look for ways that you can accelerate the achievement of those business outcomes."
From the technical and engineering perspective it may be important to understand how an SOA approach will help achieve those business outcomes, Rollings said. "But you can't go wrong with focusing on the business outcome," he added.
Technology is not a panacea
He also urges architects focusing on the business outcome to not to make their technology preferences into a religion.
When collaborating with IT and business people, he said, "It's not a place where having your own technology religion really works well. You have to be willing to accept other people's opinions. You need to be able to vigorously discuss and argue different points, but realize you have to bring a group of people along in any kind of a change process. If you're asking to implement service-oriented architecture that has a profound change in how people develop, how they incorporate reuse into what they are doing, it also has a profound change on how you analyze different project dependencies, project commonalities and how you identify those major services that are aligned with the various business capabilities."
Because those are difficult changes even for developers and other IT professionals to make and require embracing and learning new ways of doing things, Rollings says it requires constant communications and a focus on software systems that "do things in a manner in which the organization wants to see them done."
Rather than trying to impose a particular type of architectural view on an IT department or business organization, the successful architect needs to look at how an SOA approach might fit into and improve the existing business processes, Rollings said. This requires architects to ask questions and listen carefully to the answers, and then incorporate what they learn into their SOA design.
The Burton analyst suggests that the first questions are: What does the organization fundamentally want to do? What are the business strategies? How does SOA fit in?