Edge systems need a dose of SOA, too

On the peripheries of every enterprise are the "edge" applications, databases, and systems. A repository here, an embedded system there, an open source database over there, distributed servers everywhere. Corporate wouldn't give us the budget, so we went ahead and jury-rigged this thing together anyway -- so there. These systems tend not to be mission critical, and often deployed under the radar to serve a specific pain point or purpose.

Edge applications may cost five times as much as those supported by centralized SOA

The question is, should you attempt to bring these edge systems into the SOA fold? Is it even worth the effort?

Paulo Rosado and Rodrigo Castelo, writing in the latest edition of The SOA Magazine, say yes, these edgy apps (or "shadow IT") need to be service oriented as well. Because while edge apps may be cheaper and faster to implement, they end up costing enterprises a bundle in maintenance and overhead.

Of course, many would argue that most SOA efforts themselves sit at the periphery of the mainstream enterprise. But that's a subject for another post.

Why even consider SOA for peripheral apps and systems? Rosado and Castelo say these siloed projects cost more than more centralized projects, and eventually mushroom into more headaches for the centralized IT department:

"Projects deemed small (typically less than three man-months) are developed locally in technologies like Excel or Access, while larger projects get added to the central IT backlog. Such a model keeps business users relatively happy and eases the pressure on an understaffed central IT department. However, this huge assortment of 'mushroom' applications results in ever-rising maintenance and support expenditures. Without prior planning, business units end up spending up to five times more money than initially planned for supporting and evolving their applications."

They also observe that "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."