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.
2 thoughts on “For those of you who think that services solve everything…”
I think you are using the term "service" here like I use the term "interface" in OOD. In that sense I agree this is not a technical issue but a design issue. When I’m thinking of a chunk of logic and functionality I’m thinking of either a Class or any other Definition Structure from which a runtime object can be constructed. The only difference is a Class is usually maintained by the programmer but the Definition Structure (XML or anything else) can be maintained by the end user. The interface is what enables the system to not care what approach is being used.
The concept of "data encapsulating logic" bothers me. I don’t think I trust the end user’s ability to decouple unrelated processes and design good solutions using declarative methods. I’ve seen people using Excel as an ERP system – simple interactions, lots of chunks of data and logic, and zero maintainability and scalability.
I’m not saying every business rule should be written in code, but I think an iterative development process can be used to make quick adjustments from design time to runtime rules and back.
Take the idea you expressed and move it up one layer of abstraction. This isn’t a design issue either, it’s an architectural issue. Interfaces create a contractual obligation at the code level within a system. However, services create a contractual obligation at the runtime data transfer level, between systems and stand-alone components.
As for the concept of data encapsulating logic: I don’t think that end users can design good solutions without help. However, I don’t believe that we spend the majority of our time on these issues. In fact, I think that the technical issues are so daunting that many people use them to avoid discussing the business issues altogether. In other words, the end user can’t do it, but the developer won’t.
Somewhere in the middle is the notion that a business architect can chart a course and an agile system can compose services to get to that course. A business capability delivered with two orchestrations and 300 lines of code… that’s my idea of nirvana.
Excel is the paradigm, not the implementation. End users have a better idea of what it takes to build a capability by constructing services. We still need to implement them, but in an agile and dynamic manner, that allows capabilities to be delivered right up to the "noisy edge."