On 14/06/07, 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.
That is just a longer way of saying what I said. Except you don't have constraints added in on your longer one, e.g. "scalable" if it is legally impossible for more than one person to use something at a time (e.g. a security gate) what is the point of making it scalable? > > "looks like and operates like" is too soft a concept to be of any value, IMO. Not really, it is very measurable. When you have the architecture of your IT estate, can the business people understand which bits are relevant to them (without having to learn IT speak)? If they can't then you've not delivered. When the business requests change do they do so in the language of the business or is there translation from that into a "formal" change request for IT, if its the later then you've failed. When the business wants to make a change in approach is there a clear split between the IT change and the business change programmes, if there is then you've failed. Its very measurable and it focuses IT on the goal of delivering to the business rather than an obsession with technical detail. > > But FWIW, IME, RESTful systems generally "look like and operate like" > the business. That's not (or at least shouldn't be) a goal though, > just an interesting side effect. Ummm could you show me one? So far the ones I've seen look like a set of URIs and XML documents. Something concrete like warehouse stock management or risk analysis would be good examples to have. > > Mark. >
