I’ve been having a really fun discussion these past few days with some folks on how (or what) to sell to the business when you want to build apps using SOA.  Mike Kavis believes that there are three camps: (1) sell the technology, (2) sell the solution (and only the solution) and hide the SOA, and (3) sell both the solution and the technology and show how the business benefits by it.  (I cannot, for the life of me, find anyone in the first camp.  Sorry Mike.  I think there are only two camps.)

I’m all about the business benefits.  In other words, if I can go the entire conversation without bring up the word SOA (hasn’t come up yet), then I will.  From my standpoint, SOA is good design.

Innovation and Disruption

Mike Kavis posted a really thoughtful post: a real-life story of how he sold a disruptive technology combination (SOA+BPM)… as an enabler to what the business wanted to do.  Quote…

We sold the business on the benefits of BPM and then explained how SOA was the key to allow the BPMS tool to talk to our legacy systems. […]  Once the business knew that SOA was the enabler for their BPM initiative, which happened to have an eight figure ROI over five years, they didn’t need to hear anymore.

What a great story!  I love this.  This is an example of how IT can come to the table and offer disruptive innovation to change the way we do business.  That is something that happens far too rarely.  I strongly agree with Mike that this is the right approach to take in this case.

I want to make something clear: I strongly applaud Mike for what he did and the success he has had.  (Dude… if you ever want a job, let me know.  I’m drop-dead serious). Mike sold a disruptive technology to the business, and he described the technology when he did it.  If I were selling something disruptive, I would too.

But what about when I’m not trying to do something disruptive?  What if I am just trying to keep the trains running (and build new trains and track)? 

Business and IT and SOA

This year, Microsoft will embark on something like 200 substantial IT projects, with eight of them costing more than $5M each in the coming year.  Eight sizable projects.  (Total costs of IT, including data centers, maintenance, and new initiatives, will top $1B this year… which is typical.  There are 6,000 people in Microsoft IT.  This is not a small organization.)

Let’s look at those ‘big’ projects.  In each case, the need to change the infrastructure ties to business strategy (some more strongly than others, but alas, that’s how these things work).  The business comes with a strategy and we work out what the process changes are, and then we figure out what the data, application, and technology changes are.  We plan out the future state, and the business funds projects to support it.  It’s all quite collaborative.

I want to make two observations:

  • All eight of these “big fish” projects will use SOA. 
  • In the business case for each of these projects, there is not a single word about SOA.

Each project is free to contribute a bit of their funding to shared infrastructure where needed.  That gives us better monitoring and management and helps fund “tool things” if we choose to do them.

Listening to the customer means knowing what they care about

We do talk about SOA, just not with the business.  It’s not that the business doesn’t understand SOA, or wouldn’t if we told them… it’s just that they are not incented to care.  If I walk into a business meeting with the head of the Volume Licensing organization, I have to realize that his operational team books a little over $1B in revenue to Microsoft’s bottom line every month.  Let’s say I take an hour of his time.  During that hour, his organization has closed on $6M in revenue.  If I ask for $200,000 for SOA, when SOA is basically good design done well, using modern tools, many of them free… I’ve wasted his time. 

If I am spending an hour of his time, that hour had better be about increasing sales, reducing costs, or expanding markets.  That’s it.  That’s what he cares about.  That is what he signs up, each year, to care about.  He has very specific targets to hit.  People count on him.  He counts on us.  That is how it works.

Innovation on the inside

We have business process teams here, but they are not tied to composing services… not yet.  We are working on the BPM+SOA approach in Microsoft IT, but honestly, the proof of concept needs to be identified (and the planets have to align) before I can turn on the charm.  I am a huge proponent of BPM and believe strongly that SOA powers BPM to success.  When we are ready to sign up a proof-of-concept project, to introduce a disruptive technology, I’m sure we will have to talk about technology to that business customer.  In that case, sure… talk tech.

But it won’t be a huge, expensive, ‘innovation breakthrough’ project where we introduce disruptive technology.  We will do it in a test case project that can deliver quickly, and where the risk of failure can be mitigated.  I’m not going to bet the (huge) Vista business or the (comparatively smaller but very visible) XBox business on my personal pet project, and neither will those business leaders.  No one is asleep at the wheel here.  People notice when Microsoft screws up. 

We screw up sometimes… All IT shops do.  And you don’t see the failures (usually).  That is because we innovate quietly and then, when innovation pays off, we tell the planet.  When it doesn’t, you don’t see it.  We try again until we get it right.  We are a pretty persistent bunch.  It’s a culture thing.

Once the test case for disruptive technology shows promise, we will discuss it with other teams.  It will grow virally.  There is no ‘strategy’ to adopting an idea that has proven itself valuable.  It’s more like flood gates around here.  Usually too many people will rush to the good idea, and we have to tell them to take turns until we naturally grow our capacity.

SOA = Professionalism, not tools

SOA is not a disruptive technology.  Not here.  Not anywhere.  SOA is mainstream.  We don’t discuss SOA with the business because we don’t discuss professionalism or intelligence with our business… it is assumed and required that we behave with best practices and bring the best available design.  That includes SOA. 

Our stack, with WCF and SQL Service Broker side by side, and with Workflow Foundation up a level, and with Biztalk and the ESB toolkit on top, is rich and deep and very solid.  It gets better every year.  Once you know the solution you want to deliver, then I’m happy to talk about tools, because these tools will lower the cost of delivering it. 

SOA simply is not disruptive.  Not any more.

By Nick Malik

Former CIO and present Strategic Architect, Nick Malik is a Seattle based business and technology advisor with over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

4 thoughts on “SOA is not a disruptive technology (selling SOA, part three)”
  1. Hi Nick, great post.

    Im now in the Innovation and Disruption situation. We have to define and run the enterprise architecture to change the core banking system of the biggest bank in Ecuador. We are going to implements BANCS financial solution and evaluating BPM alternatives.

    But, dealing with the integration issues is where we have a bunch of ideas and SOA is in the table. We are also concerned about demonstrate it is necessary to implement a middleware to integrate hundreds of satellite and legacy applications…

    This is my first experience with core banking changes, and I’ve recently beginning with this proyect this Monday.

    I agree with you about soa = profesionalism, but I think its easier if you are taking a project from the beginnig than trying to re-design running projects.

    Also I’m evaluating if Biztalk fits into our environment. If you have some information, contacts, links, papers, etc. about why we must use Biztalk for integration I’ll appreciate a lot.

    Carlos Figueroa.

  2. Great article and thanks for the plug.  About that job offer, you obviously haven’t seen my open source articles.  You might want to retract that offer :}

    I was unable to sell SOA by itself over the last couple of years.  But once BPM came into play, it became an easy sell for me.  When it comes to selling SOA by itself, I tend to agree with the approach you outlined here.

  3. Hello Carlos,

    You asked for my help, but you gave me no way to get in touch with you.  I’d rather connect with you one-on-one than to engage in a discussion on a public blog.  

    Can you please send me e-mail by clicking the ‘e-mail’ link above on the menu bar?  

    — Nick

Leave a Reply

Your email address will not be published. Required fields are marked *

18 + 19 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.