Is REST architecture or a design pattern?

Mark Baker commented on a presentation by Roy Fielding that claimed that "SOA was a null architectural style". Now part of it was that Roy seems to think that SOA = WS, which is wonderfully naive, but a bigger bit is the idea that REST is an architectural thing.

Is it? After all what is the goal of architecture in an IT context? Surely its to represent what the business wants to achieve. Looking at the Wikipedia definition of Enterprise Architecture for instance it says

Enterprise Architecture is the description of the current and/or future structure and behavior of an organization's processes, information systems, personnel and organizational sub-units, aligned with the organization's core goals and strategic direction.

And System Architecture goes down as

A system architecture or systems architecture is the design or set of relations between the parts of a system.

Now this is what I've always thought of as being architecture in an IT context. Even something very very techy like ADML describes software architecture as

A software architecture describes the structural properties of software, typically the components and their interrelationships, and guidelines about their use.

The key bit here is it describes the OPERATIONAL pieces (components and interactions) rather than the implementation mechanics.

Now I don't think this fits what REST is at all. REST deals with the implementation mechanics and the principles and practice of that implementation, it doesn't provide you with a style for the modelling of an architecture and its interactions, it provides you with a framework for its implementation.

In his presentation Roy uses the phrase "Architecture is trying to find the common design" before going to talk more about architectural style being more abstract that that. Now the issue here is that in architecture he talks about implementation protocols as being the key to the Web "architecture". REST then becomes one level above that talking not about the protocols but about the "style" of the Web. Now this really got me thinking. This is a long way away from what I mean when I talk about business architectures and it really is about implementation practice... then it dawned on me, this isn't an argument about architectural styles, in fact REST isn't an architectural style.

REST is a design pattern

In software engineering ,a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Now that to me sums up exactly what REST is, and how the Web is the implementation of the REST design pattern, and explains how the REST design pattern can be used to implement your projects and programmes. This doesn't make REST any more, or less, relevant to decisions but for me it explains the different between SOA, as a business driven concept, and REST as an implementation model for that approach. It is fair to say that Web Services has a lack of patterns and practice and that this is an area that should be addressed in terms of Web Service implementation patterns (and anti-patterns), but both REST and Web Services are fundamentally about technology and implementation.

Architecture needs to be about understanding the goals and objectives of the business problem being solved and about the effective modelling of that solution. This then needs to be translated into technology by creating a software architectures which are based, or constrained by, firm design patterns that ensure repeatability of solutions. Confusing the goals of architecture by making it focused on the technology implementation really doesn't help us bridge the gap between IT and the business, indeed it reinforces the gap by emphasising the IT focus as being on technology rather than on the business problems.

REST may well have a place within the implementation of an Enterprise or Solution Architecture, but we shouldn't confuse the goals of architecture (business problem) with patterns (IT implementation), and REST belongs firmly in the later.

Technorati Tags: SOA, Service Architecture

Video from QCon conference

Over at InfoQ the interview that Stefan Tilkov did with me back at QCon in the UK (next one is in SF in November) is now available online, I'm talking about Business SOA and its impact on IT, with only a minor dig at the technology driven people.

Technorati Tags: SOA, Service Architecture

Professional IT and why you don't hear it

Speaking to a very interesting and smart chap from IBM at the conference today called Max from IBM Research who is looking at the Web 2.0 technologies and their growth he asked a very good question....

First the setting. There was a panel on SOA Runtime and the WS-* v REST question came up. I repeated the quote "want to be cool do REST, want a career do WS" just to be provocative really (and interestingly got a round of applause from the audience...). The proper answer was the one that Gregor said which is that there are two worlds, the enterprise, transactional and integration one (the big one) and the interactional one (the small one) and that they require different models. Something I agree with.

The discussion with Max afterwards was around what he sees as the "explosion" of REST APIs (900 at the last count apparently) and I pointed out that Oracle and SAP alone probably have double that, even before you go to internal and commercial implementations. His question was simple

"Why don't you hear about that?"

The answer?

The people who work in these area tend to be employed and doing it as part of their job. Their main interest isn't therefore in the technology as a thing but in the objective of getting it live. Tony put this well on the panel saying that "the focus isn't on technology its on operation, if its not operational it doesn't count". People who work on large scale enterprise IT therefore on the most part see technology as a tool to get the job done, rather than as the end in itself. Its also something that they do for a living and therefore "normal". This is the big reason that you don't hear from people in all of these enterprise companies, they often don't realise that what they are doing is special, because hell it works why is that impressive? The point for them is doing business better so the story is "new automated fish selling solution for the abstract art industry" not "we used Web Services to connect some stuff".

This later one is also the "where is the news" point. "Company uses Web Services successfully" isn't news, its not shiny so why would anyone write about it? News is about what is next and what is.... well "new". Doing something successfully with the existing technologies isn't a big deal, its what people expect. They get written up as Case studies where the word "Web Service" is just a remark (at best) as the concentration is on the operational solution.

Things like Java SE 6 are indicative of the problem that we face in IT these days, it was aimed squarely at what I like to think of as the ADHD part of IT, or as Andy Hedges puts it the "ooooh string" crowd. The voices from professional IT do it for a living and don't have much of an interest in raising their heads above the parapet and pointing out that they are already using Web Services and have been for many years and that they are now using BPEL successfully in their organisation. There is an assumption made that because they don't blog about it that it isn't happening.

There is a way that these people make their voices heard however, its via standards bodies, professional bodies and most importantly in the procurement of billions of dollars of IT systems, technologies and solutions every year. The likes of SAP, Oracle and IBM are the bell weathers of this market and you can see what their clients are demanding by seeing where the main focus of their work is (they often also have the "string" as well as it helps them sell better). The problem is that because these people have a day job that is focused on objectives they don't have the time to blog, join technology committees, etc So their involvement is very low per capita in comparison with vendors and the blogosphere, its also not "interesting" as its their day job so why on earth would they want to talk about it more?

As Gregor said there are two models, one around interaction and one around transaction and they require different approaches and thought. But one thing that is for certain is that it is the IT professionals in enterprises and the large software vendors who will eventually decide how both worlds will work, and as before the successful ones will continue to see technology as part of the solution to achieve their objectives and not as the objective in itself.

Convincing more of these organisations and people to get actively involved with standards and vendors is a big challenge, because they already have a day job. But without exception when they do get engaged it makes for better standards and better products.

Noise on the Web != where the dollars are going. William Shakespeare had a good line that might work here

"Life is a tale told by an idiot - full of sound and fury signifying nothing"

Or to rephrase a famous saying

"If a Web Service is deployed in the enterprise and nobody blogs about it, does it still get used?"

Technorati Tags: SOA, Service Architecture

Dave Chappell - another reason why people matter

I've just sat through a presentation from Dave Chappell on what he is looking to do at Oracle now he is there. Its a message around data-grids, high availability and scaling. Looks very interesting in terms of how it further takes Oracle away from the database (but not data) being important.

When I meet companies I place a big weight on the people there and the clarity of the vision. Simply put companies that don't have forward looking people will just produce average copies of what everyone else does. The SOA Grid presentation by Dave was a great example of this as it really talked about a problem area in the current generation of technologies (box dependency, operational scaling and database overloading) and a vision of what a SOA Grid would actually look like and what the important parts of that message would be.

One of his points was that the reason people do stateless services (although of course they aren't really stateless) is because that is the way that you are forced to scale applications today. This doesn't make it the only way to scale, just the way that you scale based on the current generation of infrastructure. Dave's proposal is that Oracle will develop in-memory data grid infrastructure that scales horizontally and only offloads to the database as a transactional store and does this asynchronously, rather than as an active datastore the database becomes a record keeper of what has already happened. This means.... LESS DATABASES and also that databases become less important... no news on whether Dave is based in Boston for personal security reasons.

My learning from this is that the vision comes from the individual, and getting it successfully delivered by Oracle will require that clarity through out the delivery process. Oracle have been very successful at hiring the smart people at the right time to help them move from being a database company that did Java badly into a middleware and applications company that does a good database. More on this in a SOA World Article that Dave wrote.

So learn from Oracle and get the people right first, they'll then get the technology right for you.

(Oh and the organizing genius behind the keynotes and the panel's I'm in was Robert D. Johnson who has the word SOA on his business card twice)

Technorati Tags: SOA, Service Architecture

SOA Governance isn't about technology either...

Today I was on a panel at the International Conference on Service Oriented Computing which was about SOA governance. The panel members were

• Gregor Hohpe (Moderator and now at Google)
• Chris Harding (who did the keynote)
• David Bressler (Progress)
• Tony Carrato (IBM)

And of course myself. Now Chris had done a keynote on Governance from the OpenGroup perspective and talked about the "Three C's" of Governance, Culture, Communication and (IIRC) Control. We had a good set of debates and I'd like to summarize a few of the points made.

1. There must be an impact to violating governance, too often people ignore governance knowing that they will get away with it
2. Governance is not one-size fits all, find appropriate governance models in different areas
3. Governance is about people and process much more than it is about technology
4. The Business needs to be accountable for SOA governance and the business Services
5. IT needs to be responsible for the delivery of SOA and the technical parts of the services
6. Too many companies are buying registries as if that is all they need to do for SOA governance (a top point by Dave)
7. Governance needs to not create big document jockey processes, it needs to be effective
8. Bad governance kills innovation (a good point from the floor)
9. Governance isn't a new IT problem with SOA, projects have failed for years due to bad governance. The point is that SOA provides a better structure for governance than previous project based approaches.
10. SOA governance isn't an IT thing, it impacts the business accountability, the funding model and the full lifecycle.
    

Myself and Tony disagreed about the most effective way to enforce governance, I preferred using a stick with nails in it while Tony felt shooting someone and leaving the body around was more effective. Personally I prefer the stick with nails as its personal, but I see where Tony is coming from :)

The basic piece though was that if you don't switch you governance model to actually be based around the services and the business then you are being wildly optimistic if you think that applying a new technology (like a registry) will solve your problem.

One of the more enjoyable panels I've been on. They were video'ing it but I don't know what happens with the videos, if I find out I'll link it.

Tomorrow its SOA Runtime headed up by Dave Chappell.

Technorati Tags: SOA, Service Architecture

Emacs 2.0 ... one instance for everyone

There have long been arguments of Emacs v vi and which is better. I was one of those who saw Emacs as the stronger enterprise tool, and vi as the quick hack it editor when you didn't have time to boot both the computer and Emacs. With all this talk of "rich desktops" and "rich applications" it made me think....

Well with Web 2.0 and Google Docs showing us the way its time for Emacs to finally dominate. One of the features I loved in XEmacs was being able to have multiple people working on one code base in one editor, just fire up a window on another machine and you are away. Both editing the same code, pair programming in the truest sense of the word.

Now we can go a stage further, Emacs 2.0, the Web hosted single instance of Emacs served up to every browser on the planet. Everyone editing inside the same Emacs session, everyone able to share the same information, everyone able to use a Mayan Calendar to plan their projects.

This is what the vi people never realized. Emacs has just been waiting for the Web to become sufficiently mature and the PCs to become big enough to really enable to true power of Emacs. Web 2.0 is that infrastructure, it will become the plumbing that will put Emacs in every browser and finally finish the argument once and for all.

Never needs to reboot, never shut it down, always available. Need to browser the web? Do it inside Emacs 2.0. Need to run a global procurement system? Do it inside Emacs 2.0.

Emacs 2.0 will run as a virtual application hosted on all of the browsers on which it runs, it will become the base Operating system install on all new PCs and servers and it will provide a single shared environment for everyone on planet earth.

One editor, one instance, 6 billion users.

Technorati Tags: SOA, Service Architecture

Why contracts help migration

Now there are some people who think that validation is a bad idea, but recently I've seen a few cases where contracts have really come to the fore again. One of these is around migration. The scenario is pretty simple, you want to start moving to a new solution area but you don't want to do it in one go, you want to clearly split the area into two pieces, the consumer bit and the producer bit. Most likely its the producer that is going to be replaced but you don't want to like the two parts tightly together so they have to upgrade at the same time and the same pace.

So what do you do? Well first off you define a formal contract between the two areas, one that can be fulfilled by the current implementation and which can also be supported by the new service when it arrives. Effectively you've now split up the two worlds and placed an agreed boundary between them which can be enforced, tested against and measured against. You are now in the situation where the new implementation has to meet the contract and where the consumer can now rely on that contract independently of the implementation.

When looking at splitting up areas, or migrating applications and software the enforcement of clear contracts is a very simple way to start introducing business centric contracts and to provide a controlled way in which upgrades can be handled for both producers and consumers. Not using contracts means there isn't something to test and validate against and thus the new implementation is aiming more at an abstract goal than a concrete reality and the consumers have nothing to rely on as they plan their own future improvements.

Contracts therefore increase the flexibility of complex systems explicitly because they enforce the boundaries.

Technorati Tags: SOA, Service Architecture

SOA is a change programme, not just technology

Now Andrew McAfee is a smart guy and I agree with what he is saying when he says SOA is Sometimes about technology but I would say that the technology is never the most important thing. I've made my point before about the technology focus problem but I'd like to take that one stage further and say what I think is the most important thing People and in particular the cultural and organisations changes that are important in an organisations successful adoption of SOA.

With any technology and process change programme there are two choices

1. Change the technology and process to fit the business
2. Change the business to fit the technology and process

Now anyone who has seen large scale package programmes will tell you that the later is much cheaper and likely to succeed. The same is true of SOA. Adopting SOA should be seen in the same way as those large scale package implementations this means there are two clear streams of change that need to be thought about

1. The process and people changes to ensure successful adoption
2. What the technology can do, and fitting the process and people to that

SOA is about shifting thinking away from big projects and towards programmes of service projects. This means that you need to change your project approval and delivery methods to fit a programme mentality. It means that your teams need to be set up as small service projects that hit the agile sweet spot and creating programme management boards that oversee the direction (but not the day to day management).

This also means that you'll want to change your seating plans so the business and architects are sitting together and talking together as a normal part of the day. You'll want to change your requirements process to be based around services, the testing process and the deployment and monitoring processes.

The technology is about understanding what there is now, and just coping with that. Don't build your own for the sake of it creating a death by technology problem just cope with what is there are look to the standards and roadmaps to understand the evolution that you have to go under. Refocus IT towards the business goals and language and learn what is really required and important and what is technology for its own sake.

Successful SOA adoption should be thought of as a change programme in the same way as vanilla SAP or Oracle is thought of. Get the technology in where it delivers value and change the organisation and process (in this case the IT delivery organisation and processes) to make it successful.

Adopting SOA technologies and not changing the practice ensure that the benefits will either be minimal or you will get the equivalent of a heavily customised package, massive overspend, reduced benefits and a nightmare upgrade cycle.

Too often I see people lob in the technology first and never have an SOA change programme. The smart companies are the ones that look at people, process, culture and technology as one thing and recognise that the largest impact comes from changing IT to fit this new approach rather than treating it just as a technology solution.

Technorati Tags: SOA, Service Architecture