For those of you who think that services solve everything...

A few days back, I blogged on "how to design a service."  It has become increasingly clear that I answered the second question first.  The first question is "why in the world would I want to create a service?"

Isn't it going to slow down the code?  SOAP is slow, right? 

History lesson:  Why services?

Many years ago (around the time Object Oriented Programming first came out), a real conversation began in software surrounding reusable chunks of code.  Before then, the only rational ways to reuse code was to copy a project from one place to another and modify it, or to integrate (system to system). 

The problem with this kind of reuse is that the granularity is too large.  If you want just a little bit of a systems functionality, you either had to go through a large amount of code to dig it out, or you had to put in a point-to-point integration, requiring changes to TWO systems, with regression testing and integration testing.  It was cost prohibitive.

The "object oriented" conversation was about reusing smaller bits of code.  The proponents claimed that much smaller bits of code, even parts of an algorithm, could be shared.  Different folks could write bits of complimentary code without ever speaking to one another.  And it worked, in a way.  The success of this line of thinking comes out in frameworks like the .Net Framework and, yes, even Java's class library. 

We got a lot of reuse, and we got a growth in frameworks.  With OO, apps became more flexible, easier to modify.  Finally, the IT department could put out an app in 8 months when previously it took 18!  Wow!

Only problem is: business changes faster than that.  It didn't matter in 1970, because no one expected computers to really change things, so changes in programs or products were done in the "people-side" and the accounting system was told after the fact.  Over time, however, most companies adopted computers into every function, and that made them more competitive due to removing the inefficiencies in those "people processes."  Now, however, we are victims of our own success.  Every time we encapsulate a people process in code, it becomes tough to change. 

So the IT department is squeezed.  Where IT departments think of a project lasting 8 months as "short," business thinks of that timeframe as eternal.  Frustration abounds.  No matter how fast the programmers go, it just isn't fast enough.  We've developed whole new software development processes to speed things up by cutting out some of the documentation requirements, and the time delays for code inspection.  This is all because business needs more speed.

Just look at what we are doing!  Instead of building systems where we only have to change a few people's jobs (the "people side"), we are building systems where a lot of people have to coordinate a lot of activity very carefully in order to change anything (IT project).

This is systemic.  It is fundamental, and it has nothing at all to do with whether the code is in C# or Java or whatever.  It has nothing to do with the technical details.  The problem is fundamental: how technology is used to solve business problems.

We have to get back to the place where a few business people decide to change things, and they do, without requiring an army of IT workers to make it happen.  

If we seperate the things that change from the things that don't (Commonality Variability Analysis) we can build our nice OO objects to withstand change.  That works well at the design level, reusing frameworks.  We've made it easier for the programmer.  However, if we want to take IT workers completely out of the picture, we need to drive things in data.  That means we need simpler interactions with more constraints, so that the data can actually encapsulate the logic. 

We need "coarse grained" frameworks, where components can be interchanged, one for another, with business users making the connections using configuration data.  The configuration data needs to be in a rich format that covers the connections but does so in a simple way.  (XML is a start).  Simple interfaces are needed to wire up these interactions, interfaces that a business person can use.  I don't want a business user defining parameters and data fields.  They should simply say "The shipping department needs to send a copy of the completed ship order to the accounting department so that the customer can be billed."  The system should know who the shipping and accounting departments are, what's in an order slip, and how to send it. 

Anything less and we have an army of IT workers to make it happen, and that is what is wrong with the system.

We need simple and clean.  We need chunks of logic and functionality, in runtime, that neither know nor care about the interaction logic.  This component, at runtime, that presents functionality but allows the business to change easily, is called a service.  The logical dissonance needed to abstract it and communicate with it is built in to messaging systems like BizTalk.  The abstraction needed to make this easy enough for your average business user to change things... is not there yet.

There is hope.  We are starting to get closer.  We have a common code framework with the .Net Framework. 

We are growing some proprietary business frameworks, in which any enterprise of a particular size and type and legal framework and market expectation can create the correct services, and they will be preconfigured to work.  These are called an ERP systems.  If you are lucky to have enough time, and money, and an army of IT workers, you can get ahead of the game.  Microsoft Dynamics has made some great strides.  We are down from an army to a platoon now.  If you are not a huge company, but want to remove the inefficiency from your systems, take a look.

Large enterprises use SAP.  Same family, different species.  An army is still required for this one.

So, the reason for services isn't technical.  It isn't because we want to make things faster or use the hardware better or improve the runtime throughput.  It is because we want to get out of the business of changing every frigging detail of every frigging program when the business decides to do something radical... like make money.