--- In [email protected], "Mark Baker" <[EMAIL PROTECTED]> wrote: > > On 6/13/07, Steve Jones <[EMAIL PROTECTED]> wrote: > > So if the goal is to deliver IT that looks like and operates like the business then ultimately it must be presented in service specific ways. > > Why is that a goal, nevermind *the* goal? What are the architectural > benefits exactly? IMO, the goal should be to deliver a scalable, > evolvable, extensible system with the right concerns properly > separated through the principled application of constraints on the > architectural elements of that system.
Mark/Steve, let's not forget that the ultimate goal of most businesses is not to create IT systems. Leaving aside governmental and charitable organisations, most businesses are designed simply to return financial benefits (whether direct or indirect) to their owners, the shareholders. A company like BP does this through the exploration, refining and marketing of oil, gas and chemical products. Ford, on the other hand chooses the manufacture and selling of motor vehicles. Citibank's approach is to buy and sell financial products. And so on. Of course the increasing competition resulting from globalised markets means that today all of these companies *require* appropriate IT systems to run their businesses. It is simply impractical to operate such companies in a cost-effective way without a significant investment in IT systems. What we need is a way to decide what IT systems need to be built, how they will interoperate with the other [human] parts of the organisation and how to evaluate their cost and effectiveness at supporting the objectives of the business. In short, the real "system" to be designed is the business itself, of which IT systems will be a [perhaps significant] part. This is where thinking about "services" becomes useful. The language of business design is very much about services, or the three questions of: 1) What will you do for me (the service)? 2) How will this help my business? 3) How much will it cost? So, we might have marketing services, finance services, HR services, manufacturing services and customer support services all making up our business. In choosing service suppliers, you care only incidentally (through the SLA) about how the service is implemented. Instead, services are considered as self-contained "black boxes". Historically, the language of IT has been all about implementation platforms and technology, with terms such as the mainframe, client/server, SQL, Java, WSDL, REST and so on. In the context of trying to design the [whole] business, this is largely irrelevant. Now, if we can use the same language to talk about the operation of the business as well as the IT systems then we are in a much better position to understand and decide what IT systems are needed to support the business. We can see immediately how these IT systems will work with the other parts of the organisation to achieve the aims of the business. And we can use the same methods for evaluating the financial cost and benefits as we use elsewhere. Although this may sound trivial, it is in fact a major step forward. So what does this mean to the choice of technology implementation approaches such as WS-Everything or REST? Clearly, WS-Everything is more obviously oriented around "services", whilst REST is about "resources". Isn't this a conflict? Yes and no. This is where I think you need to take a hierarchical (or fractal) view of the architecture, at least for two levels. As we have seen, the concept of a "service" is a useful way to partition the system that is the whole business. A business such as BP, Ford or Citibank is a massive undertaking so we need some way to simplify things and get a handle on how to design them. But once we have broken the business down into "services", each such service can be viewed as a system in its own right. Because the services are self-contained, we can take a different implementation approach to each one. Some might be dealt with by humans and manual processes. Others might be heavyweight service-oriented IT systems implemented using Java and WS-Everything. Still others might be way- cool and resource-oriented IT systems using Ruby and REST. I think it is a mistake to think that any large organisation can get away with a single technology implementation approach for services. In fact, I would go so far as to say that technology diversity is *necessary* for survival. That is, you *need* both WS-Everything and REST approaches in your organisation as well as a sprinkling of the latest technological and product trends. A fractal approach to service design can help you achieve this whilst controlling and minimising the risks. Regards, -Mike Glendinning.
