Anne Thomas Manes may once have declared "SOA is dead," but at the 2012 Gartner Application Architecture, Development & Integration (AADI) Summit she said it was crucial to a new era of application design.
"We have all of these forces now driving us to change the way we design our architectures," Manes, a distinguished VP at Gartner, told conference attendees at Caesars Palace in Las Vegas. "You're not going to be very effective at supporting the 'nexus of forces' unless you change the way you architect your services."
The so-called nexus of forces -- ubiquitous at this year's AADI event -- stands for the convergence of mobile, cloud, social and information, trends that Gartner says are fundamentally shifting IT organizations.
"The whole industry is well aware of the fact that mobile broadband has opened up a conduit to create a new relationship between consumers and workers on one side, and applications and information resources on the other," said Tom Nolle, president of CIMI Corp., a telecommunications and media strategy consultant group.
In particular, Manes sees these forces coming together to demand an increasingly consumer-driven approach to services. The key is to start with business goals and consumers in mind, she said.
"You need to think about the things that your services are trying to support," she explained. "What is the business goal of a particular service? How will the consumers of the service use it? What functionality and capability are they expecting to gain from it?" The answers to those questions should form the basis of any initiative to build new services, according to Manes.
While it may just be gaining traction today, this perspective is far from new, said Robert Daigneau, who heads Application Development at Slalom Consulting. "Services should always have been designed with the end in mind -- how they are to be consumed," he said. "But those in the SOA world have been heavy into the idea of governance first -- [having] strong control over offerings." Instead, he said, architects should first be looking to the needs of their clients.
Manes emphasized that SOA methodologies are critical to this type of services modeling. "Methodologies [like SOMG, Everware-CBDI, SOMA and SODA] force you to think about the people using the services, and the artifacts that will enable you to implement the capabilities and support the activities they want," she said.
We have all of these forces now driving us to change the way we design our architectures.
Anne Thomas Manes, Gartner
She acknowledged that while many people have been doing SOA for years, some have yet to adopt SOA design patterns, which she said are vital to building proper services today. "When you're modeling services, what you're trying to achieve is a set of business goals," she explained. "The process by which you do service-orientation is by applying a set of principles which will help you achieve those goals. How do I actually apply these principles? By using defined design patterns."
Without design patterns, she said, SOA will not enable rapid modification, and people will continue to build new applications that are equivalent to their predecessors -- and often have slower middleware. "What happens is that people replace the middleware but not the design pattern they use to build their applications," she said. "When you are designing services, you must adopt SOA design patterns."
But industry viewers also warn that SOA design patterns aren't a fit for every service-building scenario.
"A lot of people say, 'Let's apply design patterns,' and they go looking for places to use them. That's not really the way they're supposed to be used," explained Daigneau, whose recent book, Services Design Patterns, explores solutions to common service design challenges.
"There's not a bigger need for using design patterns today -- they've always been useful. It's knowing when to use what pattern that's the most important thing," he continued. "With respect to mobile, cloud and big data, there are certain patterns that are going to be more applicable than others."
In some ways, using design patterns to architect services within the nexus of forces is unchartered territory. The main challenge: There are still large-scale questions about how to build a mobile app successfully in the cloud, according to Nolle.
"You can't really dig into SOA design patterns until you've established a framework of implementation," Nolle said. "When you're interacting with a cloud service, the fact is that the fundamental economic and performance limitations of a mobile device have a major impact on the way in which it can be tied into a complex process to deliver something to its user."
But before anything else, Manes said, companies today need to be able to determine what services are needed, why they are necessary and where they will be used. In the past, IT organizations have taken either a top-down or bottom-up approach to deciding which services to build.
"A top-down approach is when a big SOA initiative group gets together and says, 'We have to identify all of the different services we need to build,' and then creates the entire service portfolio at the same time," Manes told her audience at the AADI Summit.
A bottom-up approach, on the other hand, begins at the project level and is usually focused on a specific business goal or consumer need.
Daigneau noted that the top-down approach has major pitfalls. "If you try to lay it all out there and say, 'Let's dream up all the possible services we'll need,' that's the wrong way to do it," he said. "There's always going to be something new you didn't anticipate, or something you misunderstood because you had too little information. Instead, look at the individual needs of projects and approach it pragmatically from a consumer perspective. Identify and enumerate the services for particular needs; then introduce the services as needed."
As an alternative to choosing between the two approaches, Manes suggested combining them for a new way of tackling services architecture.
She said a practical approach is to tackle service implementation opportunities as part of projects -- much like a bottom-up approach -- but also have enterprise architecture teams go through the services portfolio to identify needs and ways to consolidate, like a top-down approach.