How you know when you don't have a SOA...

You know that you're probably not living in an SOA world when your definition of application integration looks like a replay attack.

Yes, dear friends, that is what I'm having to do at the moment in order to integrate our internal procurement application with our vendor management application.  You might think that, at the very least, these 2 systems would be integrated on the back end - and you'd be right.  The problem is that each system still maintains its own, proprietary UI - and each UI defines (and essentially constrains) the way that the 2 systems are able to integrate for the end user - in this case, me.  And if you haven't been able to tell from the post so far, those definitions do not meet my specific business needs.

My automation needs are not really that out of the ordinary.  I have a very simple workflow that looks like the following.

So why then, in a company that actually creates so much of the software that makes this kind of thing possible, do I have to resort to techniques like HTTP sniffing and IE automation in order to get our vendor management application and procurement application to work together?

I think the problem is completely irrespective of any company - I think the problem lies in the way that IT organizations are traditionally organized.  Moreover, I believe that the way IT organizations are organized within most medium to large companies makes the promise of SOA nearly unattainable.

Let's take a closer look at my particular problem.  When I acquire a new article for MSDN Magazine, I need to enter information about the author 1 time, and then automate the process of creating a contract, opening a PO and optionally creating a new vendor.  This basic workflow crosses 3 back-end systems (that I'm aware of) - and there's been a fair amount of integration already between them - but only on the back end.  For me, the task looks like this.

• Create a procurement request (big long InfoPath form with a whole bunch of fields that I end up copying the same stuff into for every request)
• Create a Word doc with the deliverables schedule (info about the article, due dates, cost, etc...)
• Attach the Word doc to the InfoPath form
• Upload the InfoPath form with the attached Word doc to a SharePoint site.
• If the author does not already have a vendor ID, go over to the vendor application, fill out a web-based form with the author information (same information that I already typed into the InfoPath form), and submit the form as a new vendor request
• Rinse and repeat for every article I acquire

Now, you might say, "but come on - you're just being overly dramatic - how long can that really take?"  Generally, it takes about 15-20 minutes - not a huge deal.  However, it can become quite a pain when you're doing 3 or 4 contracts at one time, and I'm also going to fall back on general principle here - it's moronic that I should have to do it this way in the first place.

As you can see from my workflow, I was able to work around the aforementioned problems by leveraging the following.

• The nice thing about both Word and InfoPath is that they are based in XML.  Therefore, I just created my own InfoPath form where I captured only the information relevant for creating author contracts.  I then used XSLT to generate both the Word doc and the procurement InfoPath form, and then copied the byte stream of my Word doc into my InfoPath form (this simply automated InfoPath's "attach file" feature)
• The vendor application was a little more of a pain, because I ended up having to just automate IE (as soon as I can find an equivalent web service, I'll change my approach).  For this, I took advantage of a popular web testing framework, Watin.

So how did it come to this where the only practical BPA solution looks so much like a hack?

My opinion is that it has everything to do with how IT organizations are structured, and more importantly, in how IT organizations define and measure value (or contribution).  It seems to me that IT organizations measure value only in terms of direct contributions to end users.  As a result, they are generally put in the most impossible position - to try and add some level of benefit to all users in the organization.  As the size of that organization increases, the depth of value that can be added gets continually reduced in favor of adding some value to the breadth of end users.  Recent pushes towards service orientation have been somewhat successful at having systems integrate on the back end, but because of the way that value is measured, new, integrated features are exposed to end users in fixed, and many times constrained, ways.  In my case, it looks like the following - does this look familiar to you?

Again, from my perspective, this diagram looks a whole lot more like the organizational chart within the IT organization than it does a systems architecture that would help either me or Joe optimize our business processes (btw, whereas I'm sure that there really is someone named Joe on the Windows team, I'm not referring to anyone specific here).  By that, I mean that it aligns users with systems instead of business workflows. What would, of course, be more ideal is something like the following.

So let me pause for one second and state that I am completely aware that this desired end state is nothing new.  To my original statement though, I believe that most IT organizations are not setup in a way that would allow them to ever really deliver this end state because of how they are structured and how they are measured.  So, should it be changed?  Two things come to mind.

1. Structure IT into 2 tiers - a capabilities development tier and a solutions delivery tier.  The capabilities development organizations would align around systems - LOB, custom, operational (ESB), etc...  The solutions delivery organization would align around individual business units. 
2. Measure each organization differently. The capabilities development organization should be measured on how well capabilities were organized, managed, and surfaced to the solutions delivery group.  The delivery organization would be measured on the degrees of efficiency added to every business unit that was a customer.

The overall idea here is that for IT to align with business, it has to do it at much more of a granular level than what is happening today.  After spending some time observing IT organizations in different companies, I'm becoming increasingly convinced that because of the absence of this division (and particularly the lack of different goals), we continually end up with a set of systems that, while integrated and maybe even "service-oriented" on the back end, are no more helpful to our business users than the monolithic client-server apps of yesteryear.