SOA comes in many shapes and sizes, but most times when the discussion comes up, it's about the challenge of service-orienting some aspect of core mission-critical systems. To date, of course, most SOA and Web services deployments have been on the periphery. Sometimes, these peripheral projects have been referred to as "lunchroom Web services" -- only a prelude to the grander SOA yet to come.
That's why it was interesting to run across this article, published in Thomas Erl's SOA Magazine, that brings up the topic of service-orienting the periphery as part of the overall enterprise SOA strategy.
At the periphery are "edge" applications, databases, and systems are probably more numerous and pervasive than the systems found at the enterprise core. They may consist of repositories, embedded systems, open source databases, and distributed or departmental servers. Often, they are low or no-budget efforts that address a specific point solution.
The challenge is bringing these systems and their processes into the main enterprise SOA effort. The article's authors, Paulo Rosado and Rodrigo Castelo, say there's a good business case to be made for service-orienting these edgy (or "shadow IT") systems, because while edge apps may be cheaper and faster to implement, they end up costing enterprises a bundle in maintenance and overhead.
These siloed projects cost more than more centralized projects, and eventually mushroom into more headaches for the centralized IT department. What seem like small, off-the-radar projects eventually end up with "ever-rising maintenance and support expenditures," the authors say. Ultimately, they estimate, the total cost of ownership could run up to be five times as much as centralized apps and systems. Plus, they explain, "ignoring shadow IT incurs the risk of hindering your SOA evolution, overlooking potential application innovations that could streamline business process and increase revenue, and increasing expenditures in the long run due to retrofitting, and also potential security and governance breaches."
Rosado and Castelo provide four key questions that need to be asked as part of any attempt to bring edge systems into an SOA effort:
- How fast can you deploy new services in your SOA environment, and at what cost? This is an important metric to discover, since time-to-market of new services will determine how well SOA is adopted at the edges. Issues around scalability, SLAs, access, and authorization (detailed below) will also affect speed of service deployment.
- Is your SOA environment ready to deliver new services with no SLA impacts on your core systems? Perform tests on your infrastructure to see how well it scales, Rosado and Castelo advise. "Because once you provide shadow IT the requested services, you need to assure their quality of service and the SLAs of your core systems, which are now serving requests to the outside. Shadow IT systems may initially be used by only a couple of end-users but can then be rapidly adopted by an entire department. An onslaught of requests will decrease your core systems' responsiveness, making them unusable by your shadow IT and any other systems dependent on them. In the worst case, this can overload your core systems and cause them to collapse."
- Can you control which systems access which services? "Once you expose services to your shadow IT, you must somehow ensure that only granted systems can access them."
- Can you transitively assure authentication and authorization once you lose control over the information? Rosado and Castelo advise adding a layer to the SOA to manage fine-grained governance issues. "More important than just controlling which systems can access which services, is controlling which entities in your organization can access and change the information that is now accessible through your edge applications."
____________________________________________________________________
Leave a comment