SOA and EDA: SOA-selling battle goes on in blogosphere (SOA and EDA: Jack van Hoof): Interesting discussion regarding Jack's post, "SOA and EDA: Business doesn't ask for SOA". There seems to be a little bit of backlash to the argument that no one should have to sell SOA to the business. However, James puts it wonderfully when he presents the following observation:
Imagine finding a carpenter with thirty years of experience and having him ask you whether it is OK if he uses a nailer instead of the trusty hammer and nail. Wouldn't this feel absurd?Absolutely. IT architecture is actually very rarely a business issue. This is as true in infrastructure as it is in software. Which is why arguments from the business that "I don't want to share my server with anyone" shouldn't hold a lick of weight with IT. If you encounter that kind of resistance in your world, just fire back the following:
"As long as I am meeting your service levels, how I deliver them is not your concern. Like the relationship between home builder and client, we are responsible for delivering the product you pay for to required building codes (meaning IT technology governance, not business "want to haves") and contractual quality specifications (SLAs).
Feel free to "drive by the property" occasionally to see our progress (and comment on aesthetic and feature completeness concerns), but trust our professional experience to design and build the required infrastructure. As a cost center, believe that it is in our interest to drive down costs, passing the savings on to you."
This argument would probably hold true for the hosting-client relationship as well...
7 comments:
I think you are very right, James. The arguments you gave don't they exactly illustrate the essence of service orientation?
Jack
Very much so, Jack. We've always used the term Service Oriented Infrastructure (SOI) to describe the class of systems that Cassatt and other SLAuto systems address.
In fact, the relationship between Service Oriented Architecture and Service Oriented Infrastructure is so close that I wonder if Enterprise Architects shouldn't think of SOA as being both SOSA (Service Oriented Software Architecture) and SOI.
The solution is simple and has been around for many years, it's called a mainframe. Call them what you want, SLA, SLAuto, etc, the technology exists to create a robust, scalable, and highly reliable system today.
It sounds great. And you, as an IT person, just can't wait to deliver your carefully prepared speech to your business users. In fact, you may even go so far as to do that. Then the business users deliver their own little speech:
1. IT is a service organization. (Translation: You work for us, and we're more mission critical than you are. You are replaceable by VAR/SIs and by SaaS. Be careful when getting uppity with us.)
2. You have not always met your SLA's and delivered your projects on time and on budget. In fact, there is at least one major nightmare project on everyone's mind at any time. (Hey, it's software, what else is new, it wasn't our fault, part of it is business' fault beacuse of how they spec'd their requirements and then failed to deliver, yada, yada. But, fair or not, IT gets the blame. IT has more glass on its house than anyone.)
3. BTW, our new friend (insert name of Enterprise Software Sales Guy) has told us all about these topics, so we're knoweledgable too, and we think you ought to listen to us. (Very dangerous game for the Enterprise Sales guy, but if IT already shut him down, this is exactly how they'll play it in many cases because they have nothing to lose.)
4. We still remember those times when you put the needs and requirements of your own organization ahead of our business needs. You wouldn't choose the app we wanted because it didn't fit your "standards". The app you did choose stinks and our competitors, who use the app we wanted, are now running rings around us. (Yep, it happens. I've seen IT frequently choose an inferior or even unacceptible app because they didn't care and had the power to ram it down the business' throats. When it blew up, IT either lost credibility or the business suffered depending on how the culture worked. This happens at all kinds of companies, large and small, successful or not.)
You won't wean the business from sticking their nose into IT's business so long as these cultural factors persist. Earning the write to be a trusted deliverer carries with it the responsibility to be trustworthy.
Have you been trustworthy?
If not, even if it wasn't your fault, consider a more consensus oriented approach. After all, the speeches described above boil down to "do it because I say so". I try to avoid that with my kids where possible, and it is possible almost 100% of the time.
Best,
BW
PS Yep, I've asked more than one carpenter to do something differently. The good ones consider the suggestions and either comply or explain why it won't work well enough that I wind up agreeing with them.
You've "nailed" the relationship that should exist between IT and the business - I agree.
Very interesting... it is a concept I will have to fully grasp, good luck with your venture.Interesting concept and site. You'll have to keep us up to date on how things progress over time.
------------
johnpetersen
MLS
Very interesting... it is a concept I will have to fully grasp, good luck with your venture.Interesting concept and site. You'll have to keep us up to date on how things progress over time.
------------
johnpetersen
MLS
Post a Comment