One of the primary challenges organizations face when planning SOA initiatives to drive user value and make the best use of the voice communication infrastructure is that they lack architects with proper SOA skills. In fact, the discipline of software architecture is still broadly misunderstood across enterprises. Compounding this lack of understanding is the fact that there are many different types of architectural specialties, and most architects are only proficient with one or two. To be a Service-oriented architect, an individual needs a solid grasp of enterprise architecture, as well as a strong familiarity with technical architecture, information architecture, business process architecture, and data architecture. People with all of these skills are simply as rare as hens’ teeth.
Right weight SOA initiatives also require skilled architects, but they need not have the same depth of experience with enterprise architecture that architects who plan heavyweight SOA initiatives should offer. In fact, working through several right weight SOA initiatives can help season the architects you have, improving their SOA skills for the day when a heavyweight, enterprise-wide SOA initiative might be in the cards.
Developers and the Challenge of Architecture
SOA presents skills challenges within the IT organization beyond the architect team as well. In particular, SOA—like any architecture—introduces difficulties among the application development (app dev) team. After all, developers are creative types; they are an independent breed who don’t appreciate too much structure. Yet as architecture, SOA places often unwelcome restrictions on developers.
While heavyweight SOA initiatives may involve large teams with a broad separation of responsibilities, right weight SOA projects typically involve smaller, more agile groupings, where an architect may work directly with developers, testers, and other personnel on a day-to-day basis. Furthermore, if the organization is able to leverage tooling that supports such a range of specialties, the team-based capabilities of such a tool can ease many of the conflicts between architects and developers.
Such conflicts, in fact, often boil down to governance issues—what are the policies that apply to developers as they create, publish, discover, and reuse Services, and who is responsible for creating and enforcing such policies. Right weight SOA tools should therefore also include support for such governance capabilities, so that the app dev team and the architects can work together on policy creation and enforcement issues, instead of having the architects dictate such policies from their ivory tower, which typically leads to resistance from developers.
Process Specialists and the Challenge of Technical Implementation
SOA presents challenges beyond the app dev team as well. In fact, business analysts and other business process specialists must also rise to the SOA challenge. To be flexible, after all, business processes must retain their business context. Yet all too often, the technical details get in the way. If the business analysts who represent the line of business are not able to effectively interact with the architects as well as the app dev team, then this critical business context for the Services, as well as the SOBAs, may be lost.
Once again, a right weight SOA approach can be critically important for simplifying the automation of business processes in spite of the complexity of the underlying technology. In a properly architected SOA, business Services present a simplified interface to the business. If the business process modeling environment is able to take advantage of business Services, then business analysts and other business process specialists have an environment for creating or configuring SOBAs that enables them to provide value on the SOA team.
Of course, one of the most important differences between heavyweight and right weight SOA initiatives is the cost. Heavyweight efforts are predictably quite expensive, while cost constraints are often a key motivator of the right weight approach. The challenge for such projects, then, focuses on achieving significant business value with a correspondingly low cost—what you might call “big bang for the buck” type projects.
Sidestepping the SOA Middleware
Morass
Many large software vendors would have you believe that you need to purchase a lot of middleware to do SOA—but that’s simply not true. “SOA middleware” or “SOA platforms” or other heavyweight, integration-centric offerings may actually not help you with your enterprise SOA initiative sufficiently to justify their cost. Even so, there are many maturing products on the market that may truly contribute to the success of your SOA, while keeping to a lean budget. It’s important to remember, however, you can buy the best SOA products on the market today, and you still won’t have SOA, regardless of how much or how little you spend. Buying the best tools won’t make you a carpenter, after all. Remember, SOA consists of a set of best practices—a discipline to follow, if you will.
As a result, the right weight approach to SOA product selection differs substantially from the heavyweight, middleware-centric approach. In right weight SOA projects, the architecture and the business processes drive SOA infrastructure and tooling choices, which should be best of breed, as opposed to being driven by a single large vendor. It’s true that SOA infrastructure generally relies on middleware, to be sure—but most enterprises already have enough middleware. The right weight approach to middleware is to leverage those assets already in place, and fill in the blanks with best-of-breed governance, quality, management, and Service creation and composition tooling.
Leveraging Right Weight Tooling
One of the greatest challenges of both heavyweight and lightweight tooling is the lack of emphasis on SOA best practices. Most heavyweight tools depend upon older integration technologies, and SOA best practices are often bolted on.
Lightweight solutions, on the other hand, focus on the Services alone and rarely provide assistance with architecture. However, right weight solutions concentrate on putting many of the key disciplines for SOA in a single box with integrated tooling. As a result, architects are likely to be able to take advantage of such tools, and they are also configurable to participate in enterprise SOA and governance initiatives.
Don't forget to check out TMCnet’s White Paper Library, which provides a selection of in-depth information on relevant topics affecting the IP
Communications industry. The library offers white papers, case studies and other documents which are free to registered users.
Internet Protocol (IP) | X |
| IP stands for Internet Protocol, a data-networking protocol developed throughout the 1980s. It is the established standard protocol for transmitting and receiving data
in packets over the Internet. I...more |
Middleware | X |
| Application Service Programs such as Microsoft .NET platform use an infrastructure of components based on a client-server computing/network architecture with enhanced use of internet services called m...more |
Back to Communications Solutions