Sign In

Is "Guerrilla SOA" a Realistic Option When the CEO Doesn't Approve Your Budget?

From Joe McKendrick: Many advocate a "top-down" approach to SOA as part of the process of gaining organizational buy-in. But what happens if you don't get funding or support from the C-level? Can the guerrilla (or grassroots) SOA approach eventually get you to where you want to go?

12 Replies

Oh yes, it can but on one condition - stop calling your Business 'guerrilla', they like it neither in public not in private. Matter is in that the "top-down" approach starts not with CIO or CTO, it really start with C-level as a whole - COO, CFO, etC.

Service Orientation, and SO architecture as only a part of it, can be successful in an organisation only if it roots in Business and streams into IT, not other way around, IMO.

Your Business operating with business service has to realise that existing business processes are 'necessary evil', i.e. business implementation of core organisation's business services. These processes have to be extremely flexible in adopting market changes; otherwise the organisation steadily moves into extreme disbalance with market needs. However, a 'process open for change adoption' is a kind of fat-free butte: it either does not exist (because butter should be made of fat) or it is not a butter.

When your business 'processes' get understood as compositions of business services, then the only thing you have to preserve for getting needed budget is how well your proposal addresses business needs, i.e. needs of business services provided by and utilised within your Business.

There is nothing wrong with seeding SOA at the grassroots level. Every SOA initiative needs a successful internal reference to help it gain visibility and momentum throughout the organization. It is important to recognize that for SOA work, the business must buy into its vision. If you encounter initial resistance to SOA, then a modest, but successful implementation might be just what you need to win the business over. In the end, you need them on your side. Your SOA can’t remain hidden forever; to effect big change you must have commitment at the highest levels. A grassroots project might give you this.

If you are talking about real "guerilla" the main question becomes: "How much do you value your own time?" since you define the project as experimentation without executive buy-in. That often leads to a hefty amount of build-your-own activity, with ill-defined expectations for success.

I also agree that "grassroots" efforts have a much better chance of taking root - basically you are looking for a quick win with SOA in terms of quicker release and/or quality of service. That is exactly the kind of executive attention you want to attract if you want to make SOA a priority.

The ability to rapidly service-enable a technology makes for a deceptively easy entry point for SOA. It is important to keep in mind that the first couple steps toward SOA are easy, then the next steps get increasingly difficult without stronger architecture, governance, testing and virtualization activities. The real task that requires executive buy-in, and budgetary approval, arises when you intend to leverage that service and many other partner services and key systems in a complex, changing environment for real business processes.

As I discuss in my article A Classification Scheme for Defining SOA, Guerrilla SOA would fall into the System design class and Application design subclass, where you should be focusing on SOA and don't need a budget to use good architectural form here. Clearly, lack of budget will impact acquisition of tools, but there's enough open source that it shouldn't stop you unless your organization has policies against using open source software.

A great question… and one that occurs more often than one might think and most definitely more than it should. In August 2006, I had written an article on SOA Antipatterns in ebizQ. Antipatterns #3 and 4 specifically talk about this exact issue. The antipatterns are duplicated below for convenience:

Antipattern #3: Service Fiefdoms
This is the corollary of antipattern #2 (The "Big Bang" Approach). Here, instead of taking an enterprise view to the SOA transformation, each vertical silo within the company goes off on their own and recreates their applications as services within an SOA. In this case, there is the potential for a lot of duplication of effort due to the lack of an enterprise view. Furthermore, this fragmented approach to the SOA transformation often fails to create reusable organizational assets, which is one of the key benefits of undergoing the transformation that leads to higher organizational efficiency and improved cost effectiveness.

Antipattern #4: Technophilia
This is an antipattern that occurs when the SOA initiative is led bottom-up instead of top-down i.e. when the "techies" are leading the initiative. Instead of the SOA initiative starting with the study of the processes that drive the business, the technology that will power the SOA becomes the apex of the effort. Instead of representing the business, the drivers of the SOA initiative get too wrapped up in technology specifics such XML, Web Services, determining which versions of the various technology standards to use, deciding how much BPEL will be needed, etc. Ultimately, such an SOA initiative does not yield the intended business benefits of creating reusable organizational assets.

The bottom line is that several years of experience has shown that for an SOA initiative to truly achieve its objectives it has to be a top-down effort; both organizationally and architecturally.

why do you think it is OK to create a mess first - 'the first couple steps toward SOA are easy' - and then heroically overtake and fix it ? What is your 'quick win' in such case? - Is it a hazard?

'...SOA would fall into the System design class and Application design subclass, where you should be focusing on SOA and don't need a budget to use good architectural form here' - interesting, what gives me a confidence in how to do the thing if I do not know what the thing is, why do I do it and whom for? If you do not have a budget, you do not have architecture; if you do not have the architecture, you should not alter systems and applications based on YOUR wish - you simply do not know and anticipate all consequences.

If you really WANT to start Service Oriented Solution in your organisation and do not know how - ask professionals or even involve them. However, those professional should benot masters of writing services but rather professional in STARTING Service-Oriented Solutions. If you are a good driver, you, probably, will not become a pilot right away only because you familiar with the wheal and pedals, correct?

My point is this: do not try to have a 'quick win' today without considering terrible risk of dramatic failure tomorrow ('quick and dirty' approach always ends-up with 'dirty' part because 'quick' disappears also quickly)

I can only extend Tarak's anti-patterns - SOA initiative must be started in the Business, top-down with regard to IT. How you get it? There are many ways - networking, golf/tennis, wining-and-dining... It is your choice.

Hi Michael - a quick win doesn't mean a successful or properly architected SOA by any means - and I am pointing out that once you roll out more services the interconnected "mess" inevitably becomes more than an ad-hoc approach can handle. However, a quick win can get the executive attention and support needed to elevate the importance of SOA for a properly aligned effort.

My response would be an unqualified yes. Nothing succeeds like success. If you can demonstrate the positive impact of an SOA implementation at the grass roots level, then you have made major progress towards gaining that executive buy-in that you did not have before.

As most of he other responses quite correctly point out, a complete SOA implementation needs to be from the top down but that does not mean that you can't have a win with a relatively small grassroots project.

I agree that the under-the-radar "quick win" approach to addressing immediate problems will help build a case for a broader approach to SOA. Our own research here at ebizQ finds many companies have at least 10 or more separate SOA initiatives taking place under one roof. Yes, it can get messy. But like the Internet itself, these "islands" of SOA will eventually converge together in a federated way. And the beauty of federation is that centralized control is not required -- SOA needs to be entrepreneurial and based on self-initiative to succeed.

I prefer 'bottom-up' over 'Guerilla', but yes I've seen first hand that the more successful enterprises that have adopted SOA have done so at the grassroots (most studies on SOA report the top-down approach is only successful between 10-30% of the time). Certainly many of our customers choose Mule not on a strategic initiative, but but because they have pockets of successful implementations and decide to work with us to help pull the peices together.

The great thing about this approach is that departments independently find a 'mode' of SOA that works for their use case. This starts the SOA evolution process as people start to get comfortable with the organisational and infrastructure changes needed to make SOA work; essentially starting small to prove out the direction. Of course, not all will implement a well-architected SOA solution, but that's okay, think of it as the cost of adoption. Once there is a SOA initiative for the division or company there will be much less resistance and much more knowledge on the ground.

Marked by the obituary of SOA declared at the beginning of the year, people are coming around to the idea that the top-down approach to SOA that traditional vendors have been offering is not an approach that works for most organisations. Incremental adoption is far more effective because the problems SOA tackle are complex and have different characteristics in every organisation. People find it easier to discover what service orientation means on localised 'edge' problems. Only once the lessons have been learned at the edge can people effectively participate in an enterprise SOA initiative.

One of the good things about the SOA approach is that it recognises diversity and has mechanisms such as federated registries and governance to help accommodate these differences in localised deployments. A fragmented grassroots SOA approach may in theory not be the most desirable way to go, in reality its the most successful way of creating a service oriented culture in the enterprise.

A quick reading of the comments above tells me I don't have any breakthrough thought to add. So I'll just add a little history.

"Bottom up" (I agree with Ross, Joe; it is probably a more palatable term to the CIO than guerilla) SOA is following the path of "bottom-up" client/server 20 years ago. It may be hard to believe today but there really were CIOs (they were called data processing managers then) who said I can't have all these people all over the place doing rapid application development.

Two thoughts if you tread the path of guerrilla SOA -- 1) Define the scope of the project and measure costs/benefits of not doing it via SOA -vs- result costs/benefits of doing it via a SOA approach. Have this data quantified and ready to expose to senior leadership to make the case to make SOA a supported and funded initiative and expand the effort beyond the initial guerrilla project team. This will help you scale beyond the shadow IT project or stealth project and get the type of staff and support you will need to bring the SOA effort to mainstream in the organization. 2) If you cut corners to do guerrilla SOA, make sure you know exactly what corners you are cutting and how to adjust to build back in the discipline needed for scalable SOA. For instance, if you are not putting automated governance in place for your initial SOA effort but rather just standing up a quick Wiki to track service status, lifecycle and ownership type information, be aware of the efficiency and scalability limitations and be ready to adopt a more formal approach as the SOA initiative becomes embraced and adopted in your enterprise.