Posts Tagged: soa

architecture / management — 5 Comments
26
Oct 09

Service Oriented Architecture is primarily about business and not technology. Bollocks!

There’s quite a few times I’ve heard / read a gross oversimplification of architecture in reference to business and technology. And while I believe I understand the ‘essential cause’ which drives such a simplification, I’ve often felt quite frustrated at the resultant impression thats provided by such a simplification. In many ways and forms, it boils down to the statement (not exactly the same since I’m not quoting directly), quite similar to the one below :

Service Oriented Architecture is primarily about business and not technology

This also reflected in the recent SOA Manifesto which states as its very first described value :

Business value over technical strategy

Allow me to straight away start picking some holes into this :

  1. Anything that a business does – whether it is soa, software architecture, building architecture or simple plant and machinery design, to the extent (which is exactly 100%), technology serves the business goals, all technology activities (and non-technology as well) are at the end of the day about achieving business objectives and therefore about business. So why single out architecture? And even more so why single out SOA?
  2. Architecture is also about business. But its not the same as saying its primarily about business and not so much about technology. For a moment lets step away from Software/Hardware Architecture and look at Building Construction Architecture. The legendary creation of Ayn Rand – Howard Roark, for all his eccentricities and seemingly portrayed egocentric and egotistic behaviour did meet the test of business objectives to the extent of making the residents of his creations extremely satisfied. And at no point would you gather the impression that he in any manner put construction technology to any secondary position to his business context and objectives. At the end of the day thats what architecture is. It is not about making one of business or technology more important than or subservient to other. Its about effectively mapping the two to provide a strong technology solution appropriate to the business needs.

I suspect one of the important causes here is that people have forgotten that the A in SOA stands for architecture, and therefore shorn of architecture, business and technology can be seen to be competing in a non win-win form.

So if SOA stands for Service Oriented Architecture, then I must submit that architecture is the art of getting the two working together. And I am of the opinion that an exercise suggesting one is more important than other is an exercise in a field unrelated to architecture. I suspect many practicing software architects will agree with this. I suspect Ayn Rand wouldn’t disagree as well.

architecture / rest / rest-musings — 6 Comments
1
Oct 09

Service oriented REST architecture is an oxymoron

It is infrequent for me to react with a level of consternation rather than agreement or disagreement that I felt upon reading [SOA] Boris on Service, Web and REST by Jean-Jacques Dubray. Not because I disagreed strongly with the arguments presented. It is that, I disagree substantially with the assumptions on which these arguments are made. And yet, as I recollect my own thoughts a year ago – a few months post my journey into REST, I realised that there was a time that I did actually believe some of these assumptions. I also realised that it is likely that many others who are dealing with a transition from SOA to REST are also likely to be perhaps sharing similar assumptions. Without much ado let me quickly get to the central assertion of this blog post.

Service orientation is neither essential for, nor is it the intention of REST.
Not only is REST not service oriented, service orientation is irrelevant for REST


There. But why was it so important to state that ? Allow me to quote from the blog post I referred to.

I say not surprisingly because RESTafarians have no clear position on “service”, they just say REST is the right way to build a Service Oriented Architecture. Yet, REST has no concept of “service” anywhere, just resources and their shiny uniform interface, links and bookmarks. Indeed there are no services in REST. Just read the thesis.

and it further goes on to state

But I digress, let’s go back to “services”. Even Bill, in this REST-* proposal is talking about creating a RESTful interface to non RESTful services. That certainly begs the question, how can a service be non RESTful since REST is all about SOA and replaces in its entirety WS-*.

The essential issue here is the flawed assumption that REST attempts to be service oriented or it is all about SOA. Its not. And why so ? Since it is resource oriented. And whats the difference ? Read on, because that’s what this post attempts to address.

Service

Wikipedia describes a service as follows :

the term service refers to a set of related software functionality, together with the policies that should control their usage.

OASIS (organization) defines service as “a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description.”

Now lets attempt to understand a service in a little more dumbed down fashion. Lets hark back to the good old construct of flow charts and process charts. In these charts one basically divided an overall set of functionality into discrete set of functionalities and chained them together through some sequences and decision points. As an example if we were to consider a simplified retail outlet system, it would consist of steps that would support (a) ordering items, (b) receiving and reviewing items, (c) selling items. In a SOA world, these could be mapped into a Ordering Service, Receipt Service and Sales Service (you could of course come up with better names and further decomposition). But each service is essentially one of the decomposed tasks of a larger workflow. If the interface to such service could be standardised and documented it would help it to be reusable across multiple contexts. And to the extent such services are reusable across multiple workflows, the advantage of Service Orientation become obvious. And finally if such a service interfaces are exposed over the web – it is a web service. At the end of the day, each service is a reusable, composable task (or tasklet) performer.

Resources

But REST does not attempt to be service oriented. Thats because it does not view the process as a sequence of tasks to be performed. It views it as a sequence of resources under modification. To put it differently, it views the process as a set of actors who exchange resources (or documents for better visualisation) and carry out activities based upon receipt of such resources. Though not as equally apt as a process chart, the analogy here would be a data flow diagram. And what might such resources be ? Well in the above scenario, there’s a Purchase Order, a Goods Receipt and an Invoice. Those are the essential abstractions that REST focuses on. These are Resources. Just like Services where there’s no one valid set of abstraction of services, one could work out a different set of resources rather than those I listed. But the bottom line is that the essential abstractions are resources *not* services.

How are they different ?

You could build a system either way – as services or resources. In terms of being able to successfully build, deploy and maintain a piece of software, both REST and SOA are likely to be equally successful at building the software. But the essential vocabulary through which they decompose their various parts (and therefore describe their interface elements) will be different. And how is that different ?

Let us imagine the ordering service we talked about above. One way to build a SOA ordering service is to establish a interaction procedure which combines an overall protocol and a series of steps (Service API). To reduce potential errors, there is a document upfront which describes in adequate detail how such an interaction should be conducted, what are the data elements to be exchanged at each stage, and what are the necessary sequencing requirements between various steps for such interactions to be concluded successfully (WSDL). The focus here is the tasks being done and the protocol for the task instructions. In case of REST the essential construct will be exchange of one Purchase Order. The purchase order would have sufficient in band instructions about the fact that it is a purchase order and the attributes it has (in-band metadata), and formal documentation if any would be restricted to the structure of the purchase order and its data than than to the sequencing, flow or any protocol level activities. (Thats why sometimes REST looks deceptively simple to be treated as just another CRUD).

More often than not when called upon to describe a service, the description will describe what the service does, and the service interface will mirror the steps required to perform the activities. Resources on the other hand will simply describe themselves and anyone who looks at a resource description will be none the wiser about what processing exactly happens behind the scene.

Thats why I believe even if both REST and SOA can be used to build software effectively, the essential focus on resources as the central abstraction makes REST much easier to use for the clients. But thats just my opinion – you may form your own.

You cheated! REST meets the service orientation definitions you listed above

Yeah, kind of (in theory). There is one way where REST over HTTP is service oriented. Imagine a document service which could store, update, fetch or delete documents. Now replace document with resource in the earlier statement. Thats your typical HTTP service that REST works off of to implement a resource management service – but thats just a single service which is standardised for REST over HTTP. And all REST implementations will be service oriented to that extent. However the sheer simplicity and ubiquity of this service makes the associated service orientation of REST rather uninteresting and thus largely ignorable.

So next time one wants to debate the merits for REST and/or SOA – feel free to add to the tons of stuff thats already written. But don’t measure REST based on service orientation. Service orientation is largely irrelevant for REST. And that per se does not make one better than other – it just makes them different.

Note: There were many other points in the blog post I referred to that I would want to offer different opinions on. But in this case, I believed it was important to keep this post focused on an essential thought that I really wanted to emphasize.

architecture / rest / rest-musings — 2 Comments
11
Jun 09

ReST : SOA, WOA or ROA ?

This is part 4 of a continuing series of posts on ReST. So you might want to read up the earlier ones as well (chronologically they are the three posts before this)

Nice alphabet soup indeed. But what style of architecture does ReST (Representational State Transfer) correspond to.

Before we get into any definitional issues which are hugely referred to in case of such debates – I shall be referring to the currently available definitions and descriptions as available on Wikipedia viz. Service Oriented Architecture, Web Oriented Architecture and Resource Oriented Architecture.

Service Oriented Architecture

As per the definition on Wikipedia (emphasis is mine):

In computing, service-oriented architecture (SOA) provides methods for systems development and integration where systems package functionality as interoperable services. A SOA infrastructure allows different applications to exchange data with one another.

Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order that users can combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

On the topic of Service Orientation, it further goes on to state

Service-orientation is a design paradigm that specifies the creation of automation logic in the form of services. It is applied as a strategic goal in developing a service-oriented architecture (SOA). Like other design paradigms, service-orientation provides a means of achieving a separation of concerns.

While REST does attempt to solve many similar goals as SOA, I believe there lies an important distinction. The essential focus of SOA is to separate functions or automation services. An example here is to separate an authentication service from authorisation, monitoring, logging etc. A SOA architecture that consists of a number of SOA services assembles such “functionalities” into one feature consistent whole. But is that how REST works ? Only in a very vague sense even if arguably so. REST standardises the functions ie. GET, PUT, POST and DELETE in case of HTTP connectors. It is arguable that REST could be used with a different set of functions, but even in that case the function set is likely to remain consistent. This is further supported by Roy Fielding’s post “It is Okay to use POST” in which he argues

Some people think that REST suggests not to use POST for updates. Search my dissertation and you won’t find any mention of CRUD or POST. The only mention of PUT is in regard to HTTP’s lack of write-back caching. The main reason for my lack of specificity is because the methods defined by HTTP are part of the Web’s architecture definition, not the REST architectural style. Specific method definitions (aside from the retrieval:resource duality of GET) simply don’t matter to the REST architectural style, so it is difficult to have a style discussion about them. The only thing REST requires of methods is that they be uniformly defined for all resources (i.e., so that intermediaries don’t have to know the resource type in order to understand the meaning of the request). As long as the method is being used according to its own definition, REST doesn’t have much to say about it.

So across the board the functions remain the same and the data types (or media types) change. Sounds familiar ? Thats like supporting SELECT, INSERT, UPDATE, DELETE on a broad range of tables each having a different schema. An argument I make in an earlier post REST is the DBMS of the Internet. Moreover Roy further goes on to elaborate that in “REST intermediaries don’t have to know the resource type in order to understand the meaning of the request” and that “method is being used according to its own definition”. Each of this further introduces constraints into traditional service orientation. And these constraints make the field of use so narrow, that even though REST could be argued to be a teeny weeny specific use case of SOA, it could be argued to be Service Oriented to the same extent that a Database could be argued to be Procedure Oriented (since all tables support the procedures SELECT, INSERT, UPDATE, DELETE). In other words for all practical purposes REST is not Service Oriented.

Web Oriented Architecture

This is not yet a particularly widely used term yet, but I did come across a reference to it on a recent article in InfoQ “REST is a Style – WOA is the architecture“. Looking it up on Wikipedia leads us to the same sources as referred to by InfoQ – articles written by Dion Hinchcliffe. Wikipedia states it as follows

Web Oriented Architecture (WOA) is a style of software architecture that extends service-oriented architecture (SOA) to web based applications, and is sometimes considered to be a light-weight version of SOA. WOA is also aimed at maximizing the browser and server interactions by use of technologies such as REST and POX.

But I just argued in the earlier section that REST is only a very very specific use case of SOA, whereas the statement above says WOA extends SOA to web based applications. If we were dealing with objects and not architectural styles here, an argument that X is a specific (constrained) sub type of Y and X extends Y would instantaneously be flagged off as a violation of Liskov’s Substitution Principle (LSP). So something isn’t quite right here and the whole situation does not add up to a consistent whole for me. I will leave it to the reader to decide whether there exists a flaw in my reasoning here or elsewhere. My assessment is that if WOA is a collection of Web related architecture elements in addition to REST, then the only way to successfully and consistently resolve it is by saying if WOA builds on REST then it cannot be simultaneously extending SOA.

To be fair I couldn’t quite find the same worlds (WOA extends SOA) in Hinchcliffe’s writings. Referring to one of them “What is WOA ? Its the future of Service Oriented Architecture (SOA)“, he refers to another of his post “Beating a Dead Horse: What’s a SOA Again? All About Service-Orientation…” which in turn states

It’s here that John Reynolds’ well-known SOA Elevator pitch comes tantalizingly close to capturing the essence:

SOA is an architectural style that encourages the creation of loosely coupled business services. Loosely coupled services that are interoperable and technology-agnostic enable business flexibility. An SOA solution consists of a composite set of business services that realize an end-to-end business process. Each service provides an interface-based service description to support flexible and dynamically re-configurable processes.

This business view is right on, and doesn’t mean business in a traditional, white-collar way. In this context, “business” means the actual functionality of the system, apart from technical details.

There we go again on services. But Business Services cannot be GET, PUT, POST, DELETE. I would emphasise again that REST does not expose business services – it exposes some very basic CRUD services. So even if in this case there is no violation of LSP, the essential inconsistency still remains. WOA cannot be REST and SOA at the same time. This inconsistency is a bit worrying. But it is likely that Hinchcliffe meant that WOA is built on REST and is similar to SOA in terms of the goals when he says WOA is the future of SOA. But honestly I could not quite figure out how exactly he would want to describe the relationship between WOA and SOA.

Resource Oriented Architecture

The wikipedia page states :

Resource Oriented Architecture (or, ROA) is a specific set of guidelines of an implementation of the REST architecture.

REST, or Representational State Transfer (see Roy Thomas Fielding’s Doctoral Thesis “Architectural Styles and the Design of Network-based Software Architectures”), describes a series of architectural constraints that exemplify how the web’s design emerged. Various concrete implementations of these ideas have been created throughout time, but it has been difficult to discuss the REST architecture without blurring the lines between actual software, or the architectural principals behind them.

Since ROA is a set of guidelines of an implementation of a REST architecture, I think its a slam dunk conclusion that REST is consistent with ROA (for the silly reason that ROA seems to be defined using REST :) ).

Per Wikipedia, Leonard Richardson and Sam Ruby further provide the guidelines for ROA in “RESTful Web Services“, but again since the evolution of ROA stems from REST, it is unsurprising that REST is consistent with ROA.

software — 1 Comment
27
Jan 09

Software / IT Terms in early stages of abuse or ripe for Abuse

Abuse : improper or excessive use or treatment (Merriam Websters)

Ahh! That is a term we haven’t found being used in IT context too often. Have we ?

Abuse in the past

Well let us start with some terms that have been used, and in my opinion abused in the past :

Web 2.0 : If there was indeed a term that actually set itself up for abuse this was it. There was nothing in it for people to refer to and hold on to as a basic and essential premise around which it gets applied. Eventually Tim O’Reilly the author of the term had to come out with a clarification What is Web 2.0, in which he said it refers to the Design Patterns and Business Models for the Next Generation of Software. Amongst the many trends he pointed out were

  • The Web as a Platform
  • Harnessing Collective Intelligence
  • Data is the next Intel Inside
  • End of the software release cycle
  • Lightweight programming models
  • Rich User Experience

He also defined the core competencies of the Web 2.0 companies

  • Services, not packaged software, with cost-effective scalability
  • Control over unique, hard-to-recreate data sources that get richer as more people use them
  • Trusting users as co-developers
  • Harnessing collective intelligence
  • Leveraging the long tail through customer self-service
  • Software above the level of a single device
  • Lightweight user interfaces, development models, AND business models

Did Web 2.0 get abused. You bet. In many ways it was too clearly defined. But inherent in the number of attributes that were associated with Web 2.0 was the risk that anything sharing but a fraction of the attributes would want to call itself Web 2.0 (given the popularity of the term). Moreover it was actually hard not to accidentally abuse it for the same reason. However people have got around that eventually and now treat Web 2.0 as simply a moniker enhancer, and then evaluate the application or company to figure out whether it indeed is Web 2.0. The overuse of the term is leading to it becoming less relevant today

Service Oriented Architecture (SOA) : While I’m pretty sure this term has been around since early 90′s and especially used in the CORBA and Tuxedo worlds, the earliest online web page I could find which described it is “Service Oriented” Architectures, Part 1” which describes it as A service-oriented architecture is a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.. A very ironic article was “BEA Fits Tuxedo With SOA Makeover” especially considering that CORBA and Tuxedo users were probably amongst the earliest proponents of the term. Instead of seeing SOAP-WS* as one more element in a continuum of possibilities, it became the “in thing” which got weighted down by so many promises, expectations, goals and so much scope creep to its perceived capabilities. Herein lay the seeds of the disappointment one sees today especially in situations when it is doing rather well.

Lifecycle of abuse :
The following are the stages through which a term that is subject to abuse goes through :

  • Initial formulation of seed thought and early implementations or practices.
  • Further refinement of thought into a notion or hypothesis that has been tested and refined through a few experiences.
  • Success visibility by neighbours leading to greater chatter along with active promotion of the term and its benefits.
  • A positive spiral of both field successes and good PR leading to a strong mindshare
  • High mindshare attracts a large and diverse community of “second stage thought movers”
  • Desire to brand or market oneself in terms of using that term to sound “in” or “leading edge”
  • Attempts to reevaluate the terms meanings in one’s own context to achieve the best fitment leading to a term meaning modification (either newer attributes being introduced or existing attributes associated with the term getting diluted)

A term’s essential value proposition is that it manages to convey one sometimes composite and sometimes complex notion succinctly. Yet successful people, successful companies, and successful terms act as great magnets. Once a term is successful, everyone attempts to use it in their own context. This is when the term starts becoming different things to different people. Thats when it goes down the Blind men and an elephant path. Thats when the term loses its core value proposition, and people using it get steadily more confused over a period of time. One way to avoid this disintegration is to be aware of the process and attempt to slow it down by drawing attention to the core notion and value proposition of the term.

Similar to the terms above, I believe other terms are now getting ripe for being abused. However sometimes abuse leads to improper expectations and sometimes even to “<Term> is Dead” which is actually an indication of the terms abuse dying rather than its basic set of offerings which continue to do well. A couple of times I have blogged about things *not* dying are SOA ain’t dead but it certainly is transforming and Java : the perpetually undead language.

I do see many terms in Software development and IT that are in the stage where they are being abused or are starting to be abused. So before we have to bury them eventually for not meeting the expectations such abuse creates, can we rein in the abuse. I doubt it, but this post is an effort in that direction.

REST : This one theoretically should be the least likely to be abused. Simply because it is so well defined in Roy Fielding’s Dissertation. But even he had to eventually write in his post REST APIs must be hypertext-driven.

I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.

What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?

Strong words indeed. And if you think if these were against some small application, the social site REST API is the OpenSocial REST API which is a rather prominent standard (and its kind of hard to imagine google and other participants wouldn’t realise the distinction). Yet the underlying shift is that for internet based applications people are increasingly relying on simple HTTP based API and since perhaps HTTP is too bland a name to term an API with, they go with the sexier sounding REST. Not really necessary. If I have an HTTP API, its all right to call it an HTTP API. Another term that did start getting used alternatively was POX/HTTP (Plain Old XML over HTTP) but the slight issue with this term is that JSON is starting to be another data payload vehicle so POX doesn’t necessarily cut it universally.

There is another issue as well with using REST as the moniker to describe HTTP based APIs. Roy Fielding eloquently points out that REST is so different from RPC. Yet in a logical sense, many requirements for HTTP APIs are very RPC like. It is possible to represent such an API using REST semantics (instead of user/delete/123 call it userdeletion/create/123 .. a name mangling trick). Moreover REST requires statelessness, a requirement that not all applications necessarily comply with. I am not suggesting they should, just that should they choose to not be completely stateless it would be difficult to term their APIs REST. These were both issues I had referred to in my earlier post Fomenting unREST : Is RESTfulness a semantics game ? Why does REST require statelessness ?.

Clearly REST is not going to cut it as a universal mechanism of describing simple HTTP based APIs. I would suggest call them HTTP APIs, or perhaps think of a better term which is not REST since it seems rather likely that many of the HTTP APIs we shall develop may simply not meet the requirements or expectations of REST. The more we use REST the way it should be, the less we are likely to abuse it. So may I request that we use REST only when the API adheres to all the expectations as specified by Roy Fielding ?

Cloud :

I am certain the term cloud began thanks to the abstraction of internet that got used in tons of network topology diagrams. So it perhaps referred to the segments of the network that formed the entire plumbing of the internet and all the external network segments which were not relevant to the topology under discussion, and to the applications and services that resided on these “external” network segments (primarily the internet). However further along the way additional attributes started getting implied. An example is the rapidly scalable infrastructure (the scale on demand attribute). This blog is hosted on a pre specified hardware by a web hosting company. Is it on the cloud ? Its a little unclear (for certainly it does not have the scale on demand attribute). Occasionally implied attributes are multi-tenancy. IMO thats stretching it too far, multi tenancy is an optional attribute of applications and services that can be hosted on the cloud, it isn’t the attribute of the cloud itself. It would be better to keep the scale on demand attribute away from the cloud term and use it as an additional qualifier (eg. elastic cloud). However one of the effects of that is that it is leading to a proliferation of cloud related terms which is if you pardon my pun, making the situation a little too cloudy. Some of the terms are for lack of a more civilised response quite amusing eg. “Internal Cloud”. I mean if cloud represents the external segments of the network and the application and services that are hosted on them, why would one call the internal network the internal cloud as if the external network would be the external cloud. But then whats the difference between the network and the cloud. Or does the network becomes the cloud or should it be that the cloud becomes the network. This highly avoidable tendency of clouding everything also has a cloudy term for itself cloudwashing – slapping the word “cloud” on products and services you already have. See the point ? Having said that, I still think it is preferred to have a proliferation of qualified terms rather than a proliferation of contextually implied attributes into a single term itself.

So can we keep cloud restricted to the “external network segments and the applications and services hosted on them” ? Thank You. And lets keep out an eye on all the additional terms that further qualify cloud. Many of them might not make sense, so just decloud them.

*****-as-a-service :

It all probably began with Software as a Service (Saas). Saas rocks and is a term which is catching on. But it is also now getting a ton of other “as a service” followers. Just google for this and the following words crop up as the first part of -as-a-service : platform, desktop, hardware, desktop, sql, data, ui, infrastructure, PC, research, os, malware, identity management, analytics, middleware … get the picture ? Now in this current global economy where more than a third of the economy is based on services, just imagine the sheer proliferation of terms that are likely to happen simply because someone doesn’t say I offer hosted middleware, no it is middleware as a service. This blog will recast itself as Gratis chronological opinion as a service. People are going nuts, and there’s no one to stop them. In the meanwhile whats happening to the one which started it all – SAAS ? Theres something called Level 1 SAAS where each customer has its own customized version of the hosted application and runs its own instance of the application on the host’s servers. I have read at least one blog post which refers to ISVs needing to customise Saas offerings for individual enterprise customers. So rather than newer implied attributes being added to the term Saas, existing ones are being removed in a manner where any outsourced software hosting will be Saas. Pretty soon, a business unit which outsources software development, maintenance and hosting to another intra corporate business unit will start calling it a Saas offering to keep up with the pressure to seem current. Pretty soon all software will tend to Saas.

Can we please keep Saas restricted to uncustomized offerings made by other service providers which essentially rent out the use of the software they’ve built or own on an as-is basis (with version upgrades from time to time of course) ?

Mashups :

Lets just for a moment look at how wikipedia describes Mashups.

a mashup is a web application that combines data from more than one source into a single integrated tool.

I see a number of enterprise vendors starting to offer Mashup products. That in itself is welcome. I however also anticipate a full wave of rebranding of Integration Services, SOA, Portal Servers into Mashups in addition to the few new mashup features being introduced. Also expect such buzzwords to drive newer budgets and customer excitement even though relatively little has changed under the covers. Eventually the term could become all encompassing where it covers all forms of system integration and service aggregation which will eventually make it useless as a term. In the meanwhile authors of existing Web 2.0 Mashups built on Google Maps, Flickr and Twitter will be left wondering, “Hmm.. was this was mashups was all about ?”


Agile : I don’t know that its terribly abused, but when I see presentations that combine elements of Agile with layered sequences (eg documented design followed by review followed by development followed by testing) and heavy management control procedures and call it the right way of doing agile – it smacks of abuse to me. Thats like taking a cheetah, cladding him with medieval knight armour, and saying ain’t it a very nice and strong fastest animal on earth ? I don’t think it is feasible to adapt a heavy process to agile or vice-versa to somehow take on the attribute of being agile. Agile requires a migration from processes which encourages repeatability through documentation, division of work and control into one which achieves high productivity and quality through capability enhancement. This requires a reduction in the control processes and an increase in the capabilities training in a manner where the quality and control is not maintained through processes built around a replaceable workforce, but instead through a set of (relatively) informal and frequent communication channels built around a increasingly capable team.

A lighter parting note.

Finally on a lighter note a friend suggested another term that is being abused. “Software engineering – a Term that should never have been applied to software and insults engineering.” I agree even though I know the comment probably stemmed from the usage of this word in this blog’s tagline. While Software Craftsmanship has been discussed for long, I find many software building efforts not worthy of being called craftsmanship. Therefore I contribute a new term to the lexicon – Software Construction And Maintenance. This is one term (or its acronym) I am not concerned of getting abused. In fact it is unlikely to get used.

architecture / software / web — 2 Comments
10
Jan 09

Stop making SOA complex

Ever since Anne Thomas Manes set off a flurry of blog posts and tweets I was completely amazed at the discussions going around what SOA is. So at the risk of (no, with the very intention to) muddying the water furthers I decided to add my 2 cents knowing fully well that many will choose to disagree. Update: I am primarily referring to the definitional issues of SOA not the implementation issues. However even from an implementation perspective SOA is not necessarily complex. The implementation of SOA can range from the simple to the very complex depending upon the choices made from the perspective of the scope, the expectations and the technology.

The definition of SOA is quite simple – the name is the definition – it is “Service Oriented Architecture”. Services are generally software things (I don’t want to call it modules or objects or components since that will set off another debate) which offer one small focused set of capabilities through a service API. As a generally accepted set of practices such services are often intended to be coarse grained, reusable in multiple contexts and loosely coupled from each other. When an architecture is oriented around building something that is built on services it is service oriented architecture. Period.

Now that we have looked at the broad outlines of what SOA is, lets consider what SOA “per se” is not (though these aspects are not antithetical to SOA itself – they are largely orthogonal)

  1. SOA is not about business alone : SOA can be used for business services. But it can just as easily be used for building technical services. I can fully imagine a network management system which is not a critical offering of a business, yet can be built using SOA. Those who focus on SOA being for business only miss out on the big time benefits that can also be had by applying it to the technical infrastructure.
  2. SOA does not require workflow management / BPM etc. :These are often relevant, but their existence is irrelevant to whether an architecture is SOA. What is critical is if it is built using and around services. There are a whole range of possibilities of building systems or even system sets without getting anywhere close to Workflow Management or BPM.
  3. SOA need not even be distributed :While 99% of SOA systems are likely to used remotable services (ie. distributed, over the network) there is no fundamental mandatory requirement that this be so. One could potentially build a desktop based personal finance application which is built using SOA (though I do not necessarily see the economic prudence in going down such a path)
  4. SOA does not prescribe messaging or event based processing :There is no such requirement, however many enterprises choose to have such services in their enterprise mix
  5. SOA is not about web services, REST etc.: DCE, Tuxedo, CORBA, REST, XML, json etc. are all implementation protocols and/or transports and/or data formats for SOA (I have designed and built systems using each one of them, so at least I am not using their names loosely). SOA doesn’t dictate that a particular technology / protocol / transport / data format be used. It is the enterprise architecture which makes the choice. In fact, the most successful SOA transport till date is HTTP. Twitter API which offers data formatted using json or XML or HTML over HTTP is a great example of a “simple service” and to the best of my knowledge its method to post a message gets invoked more than many many million times on a busy day.

SOA is a classic case of a simple idea being force fitted into a grand panacea. If one goes by the premise that a twitter API is indeed a SOA service, how can one justify the expenditure on training, consulting, outsourcing, software stack purchasing, hardware etc. etc ? Its not that the more advanced things like BPM or WS-* or “business services” are not important. It is just that these ride on SOA – they are not SOA.

So why is there a grand confusion on this issue. IMHO it shouldn’t have ideally been about SOA at all. It stems from the following :

  1. Service identification is hard : Identifying good, clean reusable services is a non trival task. Moreover when attempted at an enterprise level, there are too many stakeholders so agreement on what constitutes a service itself can be hard.
  2. Reuse is powerful. It creates territorial issues : Once identified, the services do not necessarily lend themselves to neat classification in an organisational structure. Moreover a piece of software that is reusable is worth far more than a silo’ed piece of software. This can lead to turf and clout issues whose resolution falls in the domain of Human Oriented Architecture
  3. The Hype :Thanks to the hype one now needs to get in an army of consultants, trainers, new software and hardware stacks, simply because it is supposed to be something really new and something big.

So you essentially have service identification and building which does not necessarily align itself with organisational structures and business functions by default within the context of territorial and ownership issues getting raised while absorbing a whole bunch of new consultants, trainers and vendors. And as a result we hear things like – SOA is difficult, SOA is complex, SOA sucks and most importantly we cannot agree on what SOA is. I am not saying that these problems are not important – its just that laying them at the doorstep of SOA is not being entirely honest.

So can I please put in a humble reminder – SOA defines itself quite nicely – it is Service Oriented Architecture, ie. an architecture built around services.

And finally, couldn’t help but include one of my tweets related to current debate on whether SOA is dead – “Knock, Knock, whos there ? SOA. SOA who ? So-out-of-fashion everyones calling me dead.”

architecture / software / web — 3 Comments
6
Jan 09

SOA ain’t dead but it certainly is transforming

Earlier today Anne Thomas Manes from Burton Group posted : SOA is Dead; Long Live Services. I was just thrilled with the title. However her wording was curious and I had to read her earlier post SOA vs SOI to figure out what she meant. I quote one of her quotes from that -

Many organizations mistakenly perceive SOA as an integration strategy. But it is not. SOA is about architecture. To achieve SOA, you must rearchitect your systems. You must remove the deadwood. Every organization has too much stuff — too many redundant applications and data sources. SOA is about cleaning house. You will not simplify your environment, reduce costs, and gain agility until you reduce that redundancy.

Ahh .. there we go downhill on a semantics bandwagon again. I interpreted her opinion to no mean that if you don’t do rearchitecture you are not doing SOA in a manner thats going to be helpful, and that is what is dying. Thats a little bit iffy. Its also a function of the goals and the context of the organisation attempting to implement SOA. I really don’t think there’s one black and white answer to that problem.

So is SOA dead ? Most definitely not. In fact it has never been healthier. However it is going through a transformation which is infusing all that health into it. Let me dwell on the nature of this transformations.

Some things about SOA are dying or likely to die.

    Vendor driven hype : This has always been one of its weak points. The SOA one used to see was based on hype by vendors while todays SOA is being popularised through success stories on the field (eg. Twitter / Facebook API). One of the problems with this was also the fact that the vendors were pushing WS-* stack which is a rather expensive set of standards and tools to work with. Instead today’s SOA is more and more REST based.
    Top down SOA evangelising :Earlier attempts at SOA were attempting to use top down approaches at evangelising. Todays SOA is being popularised through small success stories which attract attention on a small and regional scale, an attention which then slowly expands its mindshare.
    Enterprise Governance of SOA: This was perhaps a bad idea to begin with. If you are anywhere into trying to figure out the right governance strategies for SOA, my opinion would be that you run as far and as fast as you can away from where you stand. The russians tried it with their economy, so did the chinese, as did the indians with their mixed economy. It doesn’t work. If you want SOA to succeed decentralise and de-establish control. Instead let go of the central control (read enterprise) and provide incentives for success and innovation at a local (read application) level. Thats not the most efficient way but is most likely to succeed.

Helping to increase the probability of success is the relative ease with which one can now implement web services (a comparison of shift in single sign on models over the last 20 years will make that obvious). The internet already provides an environment which rewards innovation and risk taking at a local level which is helping make web services such a huge success story. Corporates and Enterprises will need to figure out a way to decontrol but instead reward service sharing and innovation if the same success story has to be repeated on their intranets and extranets.

So the SOA we see today is much more organic, lightweight (REST), unplanned. It very much models the two successful lifesciences and economics models – Darwins theory of evolution and Capitalism. And thats a SOA thats succeeding where SOA based services are akin to a organism or a business unit.

Coming back to the point Anne raised – is rearchitecture required for SOA to succeed ? Why is that question even necessary – let each local cell decide for itself whether rearchitecture makes sense in its own context. Some will rearchitect and some will find ways to succeed without rearchitecting. Quite frankly it doesn’t matter, since so long as each element in the whole assumes more service like characteristics, SOA will succeed.

The SOA the vendors were selling to us is dead. Long live the organic SOA.