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

Posted by – October 26, 2009

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.

Related posts: (Automatically Generated)

  1. Service oriented REST architecture is an oxymoron
  2. Design Characteristics of REST / Resource Oriented Server Frameworks and Clients

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

Closed

  1. Sushrut says:

    Well put and agreed.
    Even goal for design of a particular domain object(including data type for attributes) is towards satisfying business requirement so stating same is true for an architecture is unnecessary.

  2. Simon Brown says:

    My experience suggests that if you don’t focus on the business with SOA, you miss out on the reuse opportunities. Most teams I’ve worked with that dived into SOA from a technology perspective (e.g. buy an ESB, make everything a web service) missed out on things like shared services. You’re right that SOA is about the business and technology, but it does (IMHO) need to be approached with the business in mind first.

  3. Willy says:

    > technology serves the business goals…
    In theory yes, but not always in practice, and it is the loss of focus: making the technology more important than the business, the big problem of current trends in IT.

    >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…
    Any Architecture must be designed to serve a purpose (business goals), not to use a specific technology. Only under the construction the technology matters, after that, the technology matters just because it “serves the business goals”. Therefore the business goals should be more important during the design of the solution (architecture) that the technology itself.

    >So if SOA stands for Service Oriented Architecture, then I must submit that architecture is the art of getting the two working together
    That’s right, in fact “value over the other” does not mean reject, but the technology works to get the business goals…

  4. Simon, Willy,

    As I mentioned in the post, I understand the causes which led to the statement .. the same as what you talked about. The difficulty I have is the way the result gets articulated is a gross oversimplification which isn’t helpful.

    For all the situations where technology considerations may have become more important than business, there are many (probably no fewer) where the reverse also is likely to have played out. And thats why I resent the A is more important than B. (I dislike that statement for any values of A and B). Architects understand architecture is about making technology work towards meeting business objectives no lesser than a person designing a Coke can manufacturing machine. But SOA seems to have this particular proclivity of attracting opinions which keep on talking about Business more important than Technology. I think we are in a world where technology continuously exposes, enables and delivers on newer and more creative capabilities, and the trick is in making them work together and the oversimplification risks the appropriate technology potential not being leveraged.

    The intent or architecture is optimisation in a collective sense and not maximisation or suboptimisation in an individual sense. Its really like formulating a linear programming problem with an objective to optimise a goal (be it costs, revenues, headcount etc. etc.) around a number of constraints formulated using a number of parameters. Saying A is more important than B is like saying one of the parameters is more important than other – which I contest – its the “objective function” (in linear programming parlance” that is important. And thats the job architects are really supposed to perform.

    When we start saying A is more than B, I have this nagging suspicion that more than architects are really starting to muddy the waters. Thats why I remind ourselves – we seem to have forgotten the A in SOA is Architecture.

  5. Anna says:

    >1.Anything that a business does – [...] 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?

    (focusing on a question “why signle out … SOA”)
    I’d be delighted to dive in a deep conversation about the resoning. Instead let me pick just one argument: measuring. How does SOA implementation measure its success and reports it back to the business? Afterall many times it is comparable to changing foundation of a house – what builder or architect can do that without justifying it to the house owner? without showing metrics or any measurable facts after it is done?

    When business asks IT “we need this new system” and allocates $$mln to make it happen, eventually in any healthy scenraio, that business (read: the requestor) is required to present justification (=metrics) how it is going to help the business and what’s the ROI.
    Many SOA projects were initialized by IT side of the house with IT justification (if any) but very slim if any presentable value for the business. Not to mention that ROI and metrics associated with those projects were not made visible to the business after the delivery – which impacted an opinion that SOA is a big long cost that sometimes doesn’t even make it to production.
    …and led to a general opinion that says: SOA does require business justification – it is not to single out SOA but rather to remind that SOA, the same as any other initiative in the enterprise; requires business justification.
    (side note: Not all SOA implementations are as above – quite honestly there is a mixture, I myself have seen and participated in very smooth ones too; )
    no matter how much we’ll defend or attack this opinion – it is a public opinion and public opnion is typically made by majority… :)