SOA is not a disruptive technology (selling SOA, part three)
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.