We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.
Start a Discussion
SOA
user-pic

Does it make sense to outsource SOA?

Vote 0 Votes
As pointed out to me by Soumadeep Sen, this article at CIO, Why I Outsourced Application Development to China, gives some lessons learned on IT outsourcing.  Do you think it makes sense to outsource your SOA?

17 Replies

| Add a Reply
  • I don't think one can outsource SOA but one can do that with SOA services development. But why bother with development when one can outsource to Cloud SaaS?

  • SOA is not only about IT. To make your SOA successful you need to involve the business. The business must take ownership of services; in how they are designed, used and evolved. If the business does that, outsourcing development may be OK. If the business people don’t get involved your SOA will not be a success – outsourcing or not.
    So the key question is if the way you outsource development gets in the way of business involvement? If so it is a recipe for disaster.

  • I think the following paragraph from the article can help understand the context of the question:

    "...Tactically, Lee wanted to replace Interval's core applications and move to a service-oriented architecture (SOA). Strategically, she wanted to create an agile IT organization better able to respond to changes in the business. Outsourcing new application development to an offshore provider with experience in SOA and agile development would enable a quicker—and cheaper—transformation on both fronts..."

    Noteworthy points include:
    1. SOA was seen as a tactic for realizing the agile IT strategy.
    2. Only new applications were being considered for SOA.

    So, while the approach Lee took might have achieved her vision, I have fundamental disagreements with both points above.

    First, SOA is not a tactic but a long-term strategy for achieving an agile IT organization. In fact, most of the so called "failures" can ultimately be traced to a near-sighted, short-term approach to SOA.

    Second, limiting SOA to only new applications and their development misses a primary benefit of SOA - the benefit of breaking down the highly fortified silos of functionality to create a more transparent, open, and collaborative IT environment.

    So, in conclusion, while outsourcing application development definitely makes sense, outsourcing "SOA", in my view of the world, does not.

  • There are elements of Architecture efforts (EA, SOA, etc.) that require organizational-specific tuning - especially in areas of Governance. At some point one could certainly outsource the hosting and development of services to another firm as maturity grows. I would not advise outsourcing (i.e., toss it over the wall) the development of the governance or strategy. Hiring consultants to shorten the journey makes sense (disclosure - I am one of those consultants), but in the end the firm needs to own the governance and make it happen.

  • The extent to which you can trust an outsource partner to help execute your SOA strategy depends upon their level of expertise and experience delivering similarly complex scenarios for companies like yours. We have worked with a couple very strong SI firms that have the architectural and delivery chops to deliver for clients - and we've also come into situations where the company is still in recovery from a fragmented SOA approach.

    Rather than "outsourcing SOA" as a whole, most companies obviously outsource some phases of component/service development or testing. The ability to distribute the workload among multiple teams to support loosely coupled components that contribute to the whole solution, should be one of the benefits of a SOA approach.


  • I am not sure if the question makes much sense. SOA is an approach .. what part of this approach is thought of being outsourced? On the other hand, SOA approach that enables loosely coupling, makes outsourcing easier!

  • Exactly what does it mean to outsource SOA? SOA isn't a function, so you can't outsource it. Can you outsource the development of your services? Sure. Can you outsource the analysis required to define a service portfolio? Probably not, but you could certainly bring contract resources in-house to do it.

    In this blog post from Dec. 2006, I commented on SOA and outsourcing. In a nutshell, defining your service portfolio, which should be an insourced or contracted activity, enables you to make better decisions on what services can be outsourced or not, essentially getting you to a core versus context decision, to use terminology from Geoffrey Moore's book, "Living on the Fault Line."

    If you apply the term "service" in an even broader, ITIL like sense, you can still use the service portfolio as a tool to decide that software development, for example, is a contextual service and can be outsourced as a whole, if that makes sense for your organization.

  • SOA can make it easier to fine tune what to outsource and improve success of outsourced app dev projects. Creating an optimal service portfolio and defining good services i.e. repeatable business capabilities, requires a good grasp of business requirements and domain knowledge. Such work is usually best kept in-house.

    Well-defined, loosely-coupled services do make it easier to outsource the development, operations and maintenance of those services. Similarly well-defined, loosely-coupled services are easier to leverage in outsourced app dev projects improving their chances of success.

  • The discipline of SOA would be difficult to outsource because as Herbjorn points out, the business units need to communicate the requirements, business value, and metrics as part of adopting SOA. This is a key tenant of using Enterprise and Business Architecture as the framework for capturing the service requirements, mapping these to organization goals and metrics, and then using these relationships to derive the proper SLAs and governance models.

    This effort, while possibly aided by consultants required deep organizational knowledge and active participation by IT and the business.

    But once you have captured the need and established the controls, the who and where the SOA development and operational support sit is wide open.

    The outsourcing of SOA development is often a no-brainer, provided you have the proper controls in place – which Marie Lee highlights.

    The operational aspect of running service busses and other SOA infrastructure is a bigger question.

    If your SOA modeling is sufficiently rich, we find it is possible to analyze your service requirements in the context of business value and impact and develop an architecture that will likely be a blend of in house and outsourced SOA operations.

  • Agree with Herbjorn, Todd, and others: you can't outsource a philosophy or best practice (which is what SOA is). You can, however, insist that an outsourcer adopt your service-orientation methodology for whatever projects they may be working on for you.

  • If the out-source company is good at processes, then perhaps using one for service development would benefit your SOA governance goals.

    But to be of any lasting value, you would have to import their SOA architecture and design patterns. Otherwise you would just have an isolated island of services.

  • Outsourcing infrastructure services can make sense... if done with care and ensuring communication with business requirements is not impaired by the additional layers of control and development.

    But many services need to be agile, and agility is best served by maintaining close links between business and associated IT services. SOA can span outsourcing, but outsourcing is not necessarily a best practice for business IT service development and maintenance. Outsourcing operational service deployment eg to a cloud of course can make lots of sense!

    One example: consider the business logic in an IT service. Is the refinement and development of the business rules going to be outsourced? Who is going to own and specify the rules? Will the decision services that result be under the control of a subcontractor? etc etc.

  • I believe implementing SOA gives the perfect architecture to outsource what you are prepared to outsource while keeping the crown jewels in your internal systems.

  • It definitely make no sense to outsource SOA.
    SOA is about Business and IT Alignment. It may require changing Organizational Culture (see my post SOA and Corporate Culture Change http://avirosenthal.blogspot.com/2009/11/soa-and-corporate-culture-change.html)and changing some Business practices and adding new roles.
    External experts lack Business specific knowledge and therefore can not replace intenral employees.
    It is possible to outsource parts of the SOA initiative such as specific Service development or purchasing external Services.
    The only exception to this rule is in case of Outsourcing all IT activities. It that case the outsourcer is practicaly the IT department of the enterprise.
    By the way, there is nothing new as far as Outsourcing Best Practices are concerned. Usually it is not a good idea to Outsource unique Business related systems differentiating the enterprise from its competition.

  • I agree with Herbjörn that geographic proximity between team members is a good agile practice. Distribution (which goes hand-in-hand with outsourcing -- if we talk outsourcing in the sense of off-shoring) means that collaboration between customer & implementation crew is inhibited. When time zone and language issues creep in the situation is exacerbated. However, it certainly is possible.

    Apart from this design-time phase then there is a runtime-phase. In a cloud setting it would be most natural to outsource operations and use a cloud provider. And development may be different then when starting from scratch in classic on-site development project. The cloud provider/platform may have a specific programming model (as in PaaS) and basic primities (eg for data storage) that a cloud-deployed application would use. This gives economies of scale but reduces flexibility. A trade-off very nicely described in the article "Head in the Cloud, Feet on the Ground": http://msdn.microsoft.com/en-us/library/dd129910.aspx

  • The range of responses on this topic is interesting! Perhaps the reason for this is that there isn't a binary answer of yes or no. The answer is that of course that many aspects of SOA "can" be outsourced; but each is likely to be addressed in different ways. For example:
    - reference architecture - most enterprises will not develop their own reference architecture; they will acquire it from various sources. My organization has provided many enterprises with prepackaged reference architecture because they don't want to reinvent the wheel!
    - service architecture and service portfolio plan - many organizations will adopt pre-existing service architecture and portfolio plan including semantics from suppliers such as SAP and Oracle.
    - standard services - same
    - custom services - a comprehensive service specification integrated with ITIL SLA is a perfect basis for outsourcing. Don't expect it to act like a legal contract, more like an oil pipeline, where the contract is signed on the day the oil flows.
    - I could go on . . .

    Down the line enterprise systems "will inevitably" operate in the cloud and be comprised primarily of standard services integrated with customizing components. See my blog: http://tinyurl.com/3yycvvk

    SOA is synonymous with separation of provider and consumer. QED.

    David

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT