BT

Development of a SOA Manifesto

by Mark Little on Oct 11, 2009 |

Steve Ross-Talbot points out that there's some new work going on in defining a SOA Manifesto. Along with Steve the working group consists of people from IBM, Oracle, Red Hat and others. According to the SOA Manifesto pages, the manifesto will be ...

A formal declaration of the principles, intentions and ambitions of service-orientation and the service-oriented architectural model.

And as well as eventually being published on http://soa-manifesto.org/, there's also a meeting of the working group coming up very soon:

The "Towards an SOA Manifesto" Working Group is dedicated to producing the SOA Manifesto. The SOA Manifesto will be announced for the first time at 4:45 PM CEST on October 23, 2009 during the closing conference keynotes at the 2nd International SOA Symposium in Rotterdam, The Netherlands.

As Steve points out:

As a participant I started to look into what is out there and I must admit I am really surprised at how little there is for SOA. Of course we have patterns and principles and even governance [1, 2] for SOA but as yet no one has written a manifesto personal or otherwise to share with the industry as a whole.

He then goes on to discuss a couple of key areas where Steve thinks the working group needs to focus.

  • To ensure "that executive sponsors across industries understand what [SOA] means to them." This includes the impact of SOA on their revenue and costs (after all, successful SOA should be driven by business needs.) Furthermore the realities of SOA lifecycles (e.g., an iterative approach to getting what is actually needed, which may not be what was initially requested) should be "effectively articulated to business sponsors [to] help them make decisions."
  • As a community we need to arrive at a consensus that helps people understand what service-orientation really means, the principles behind it (business as well as architecture), and what constititutes a SOA (perhaps related to one of the SOA reference models?) Although this may seem obvious, as Steve goes on to point out "[...] in my world I often have to deal with people who equate WS-* to SOA and equate ESB to SOA. Which of course is not the case. They may help and even constrain and SOA but they not make one."

It will certainly be interesting to see what comes out of the working group efforts in the next few weeks. However, if you could provide input to it, what would that include?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Obituary? by Sebastian Kübeck

Isn't this rather a obituary than a manifesto?

Re: Obituary? by William Martinez

Sounds like the old SOA is Dead slogan. Personally I think it is a good thing to let SOA be reborn, but in good. What worries me is the working group members are from the tools companies, so I expect to see a redefinition to match the tools, which is why SOA is not working now.

William Martinez Pomares.

What is Service Orientation? by William Martinez

From the soa-manifesto.org/ site:

Service-Orientation.
A design paradigm comprised of a set of principles that shape software programs into units of service-oriented logic in support of attaining a pre-defined target state represented by the goals of service-oriented computing.


I don't understand. Sounds like a recursive definition!
Simply: Service-Orientation is a design paradigm that uses the service metaphor, where service is defined as a business functionality, defined in the business domain, and exposed using a technology neutral uniform interface.

William Martinez Pomares

Re: Obituary? by Jean-Jacques Dubray

This is the definition of Service Orientation posted on the site:
A design paradigm comprised of a set of principles that shape software programs into units of service-oriented logic in support of attaining a pre-defined target state represented by the goals of service-oriented computing.

How can I say... I am not sure this is a good start. Even though people like Mark and Steve bring advanced SOA concepts to the table (WS-CAF, WS-CDL), I am not sure many others are interested in changing the status quo. The references to SOA-RM or SoaML do not sound encouraging either. I'd be more encouraged if people from the SCA side of things would be involved, let alone listen to.

Anne is giving a keynote at the SOA Symposium next week on the theme "The Reincarnation of SOA". I'll let the readers make their own conclusions.

Re: Obituary? by William Martinez

Oh, well, Jean-Jacques.
That is what I mean when I mention tools. Although specs like WS-*, reference models like SOA-RM or description languages like SoaML may help, even SCA, they are to close to implementation to be good for a definition of concepts.

I think of web services concept, when I read the ideal, and then I see the right click-generate, I see two different things. Oh, wait, I don't have a pure document style message driven thing, but I do have an RPC one, let's just tweak a little the definition, and use document style but force the document to be like a RPC style and everybody is happy.
Define something from the tool perspective is not always good, if ever.

William Martinez.

Re: Obituary? by Paul Korney

Sadly, I agree that this is tool driven and IT sales focused, so yawn.... No disrespect to the participants here, but the problem I see daily is the virtual non-participation of business units in IT projects. I don't think SOA priciples are what is lacking - pretty much any decent IT manager can spout this adequately enough nowadays. A manifesto that speaks practically to business units, that makes IT important to them - something of bottom line value - is what really is needed. Vendors: Any help for us with that?

Re: Obituary? by Jean-Jacques Dubray

I am not sure what they chartered to accomplish, tools or otherwise, but this working group has all the ingredients that made previous attempts fail miserably: abstract beyond belief, pump & dump analysts, "we know SOA" attitude,...

>> I don't think SOA priciples are what is lacking - pretty much any decent
>> IT manager can spout this adequately enough nowadays.
I beg to disagree, hardly anybody talks about Service Versioning even though this is probably the keystone of SOA (and critically missing in REST). This is so important that it should be part of SOA. This group seems to be no different than others on this topic.

Hardly anybody understands the relationship between BPM and SOA and again this group seem to have all the ingredients to pass well below the radar on this topic.

Re: Obituary? by Jean-Jacques Dubray

William:

the problem is not point&click tools, the problem is the runtime on which the tools operate. Once people will understand that there is a difference, a fundamental difference between an operation and a method, we'll have made a fundamental step forward. Most Distributed Object gurus can even start to grasp the difference, so it is no surprise that of these people will get it wrong. No matter where you look each vendor, open source or otherwise, spent all their energy to make SO look like DO and then analysts come and claim, SOA failed. I am not surprised, DO simply does not work for constructing information systems: the abstraction is wrong and the runtime activation model is wrong.

Tools are actually extremely necessary in SOA precisely because of the lack of SO runtime (except for SCA which starts addressing some of the problems) I don't know any other runtime that even starts to be able support SO. My preference would be to create entirely new runtimes, but will this group have the courage to call for that? Steve certainly would have that courage, but who else?

Re: Obituary? by Paul Korney

Jean-Jacques,

>> ...hardly anybody talks about Service Versioning...
Agreed that this is often an afterthought. However, my point was once this, any many other critical technical issues are worked out, a decent IT shop can probably move in the right direction *technically*. I've seen it happen. But in the end, the same problems keep occuring over and over with every project: lack of direct business unit involvement means that the value that can be delivered by an IT effort is very, very limited.

>> Hardly anybody understands the relationship between BPM and SOA...

Now you're talking my language, but this relationship should be obvious to anyone claiming knowledge of SOA. The fact that it's not just tells me that the focus is still on IT departmental concerns rather than business concerns.

The 'Service' in SOA means 'Business' - talking about anything else is a waste of time (and so far, huge amounts of money). If someone wants to write a manifesto for SOA, it really needs to be in business terms for business people. Otherwsie it's just more IT industry marketing.

Re: Obituary? by Jean-Jacques Dubray

I am not as clear cut on the question. I think the business should be involved carefully (or else could be spooked by so much jargon and technology). The problem of assigning ownership to the business is reuse. Not everyone likes to share his/her toys. I prefer IT ownership with charge back to the business.

More generally, I think Service Oriented Computing is more important to get right than the business aspect. It happens that in some clear cases the ownership boundaries are well defined, but I prefer keeping the business away (after trying to get them involved). I understand that this is a preference and not every company is the same.

Re: Obituary? by Steve Ross-Talbot

Tools vendors only! So NOT TRUE.

Cognizant is a 70,000 person systems integrator. We use pretty well all tools and software products but we do not build them.

So there is at least one non-tools vendor involved. If you add it Thomas (he is not a tools vendor either) and Anne then the statement is so very wrong indeed.

All of the participants are there on merit and merit alone. It is not based on company affiliation. I think you will find everyone open to suggestion because only by listening can we hope to deliver what is needed.

So rather than brush it all off engage and take a more positive stance. Certainly I would expect Jean-Jacques (given his history, contribution and involvement) to provide key input into the process.

Re: Obituary? by William Martinez

Jean-Jacques,
Please, do not take me as a simplistic generalist that focus on non-related topics to promote hate for tools. I mean, I'm not saying SOA is a failure because of point and click.

Actually, I do agree completely with you in the SO vrs DO topic. Not so much about the runtime, but surely on the confusion developers have. To be more direct: Developers want something easy to do. Their minds are molded to use RPC. So the tool vendors do their job to get developers what they want: a point and click RPC generator. Now, buzzword are services, so they name that a service and every one is happy. We may blame it to the developers that do not know what they ask for, or to the tool vendors to provide that under a buzz name, either way the problem lies in the mind shift, and this is hard to achieve if you have a square DO mind, or a huge investment on already selling tools.

I do not say let's get rid of the tools. I say do not use them to conceptually define SOA, it should be the other way around.

William Martinez Pomares.

Re: Obituary? by William Martinez

Hello Steve.
Sorry, do not take me wrong. I didn't want say you all were tool vendors, nor I wanted to discredit any of the members.
Let me quote myself again:

Personally I think it is a good thing to let SOA be reborn, but in good. What worries me is the working group members are from the tools companies, so I expect to see a redefinition to match the tools, which is why SOA is not working now.


My point is simple, and you can read part of it in the response to Jean-Jacques: I do think it is good to rightly define SOA, but I'm worried I see tool vendors which, to me, means bias toward the concept those tools have now about services. Nor I'm saying the people there are not the greatest people on hearth. Shouldn't they be, then I would probably post a couple of names to replace them. But that won't take my worry away.

Sorry If I didn't sound positive, that was what I tried with the first line. There is hope and worries. And I set my expectation. If I read the Manifesto and I see the expectation was completely wrong, Great! But I see no open discussion, just an info email and a very short time notice that the manifesto will be presented this month. That suggests me a closed group of persons that work for tool vendors and tool users will define (or already did) what SOA is. They are great people, but what tells me their good intention comments and suggestions are not biased by their tool knowledge?

Let's start with the Service-Oriented definition. It is a recursive definition, to my taste.

Well, I wish the idea the best, and I hope the final product is the answer to improve.

Cheers!

William Martinez Pomares.

Re: Obituary? by Jean-Jacques Dubray

>> I say do not use them to conceptually define SOA, it should be the other way around
well, let's keep on dreaming, because this is all that REST is about, throwing away all the little advances had been achieved heroically one by one. XML extensibility, gone, orchestration gone, choreographies gone, assemblies gone, events gone, reliable messaging and transactions gone, bidirectional interfaces gone, forward compatible versioning gone...

So I am not sure that we will ever see them back. We can thank the analysts, the vendors, the DO gurus... We can even thank the SOA-RM, SOA-RA and SoaML working groups for painting such an abstract view of SOA that no one wants.

So I don't know what this group can do frankly other than hashing SOA-RM,RA and SoaML into a new document. We don't need any more abstractions. We need extremely practical views on how all these concepts fit together in a programming model. Take forward compatible versioning, 99% of the people don't even know what I am talking about. 100% need it but why would anyone talk about it? Again, I bet this group won't even talk about like SOA-RM, SOA-RA and SOAML.

Re: What is Service Orientation? by Steve Ross-Talbot

I think one critical success factor is that "the proof is in the eating". In a year from now we will know if the manifesto has done its job. What is really important is for you and others on this list make sure that your voice on what that job is is heard loud and clear.

If we, as manifesto signatories, do not take your voices into account then will not have executed our responsibilities.

But I am sure we all will.

Cheers

Steve T

Re: Obituary? by William Martinez

Oh, well, Jean-Jacques, REST is another story.

I actually defend REST and SOA are not competitors. I've seen a lot of REST used where REST does not fit. And even REST fans asking for versioning and clueless on how to get it. Ironic?

So, put it simple: REST is a style for networked APPs, which are different that distributed APPs. SOA is being used for distribution where is does not fit well, as it fits integration. Integration has been done bottom up, from legacy, old IT topics to new business topics. Of course nothing works.

Trash everything and start over? Probably not. I would wait for the manifesto, and take it not as the final word, but the beginning draft of a SOA reborn.

William Martinez Pomares

Re: What is Service Orientation? by William Martinez

Steve:
Who else, besides you, is reading this list for feedback? That is a sincere question. Is there any other forum where signatories can heard us, with guided discussion topics, feedbacks on proposed drafts and so on? (make it moderated, to avoid simple complains).

I may assure you there will be many people willing to help you out guys. I know several with pain stories from tools and service concepts that made them want to quit.

Wish you good luck, and if there is an open ear, please let us know!

William Martinez.

Re: Obituary? by William Martinez

Well, in this one I tend to agree with Paul.
Services is a higher level metaphor. It is a business functionality exposed. IT has diminished to a call with some parameter.

Business should not own this, but they should be pinged as what do they need. IT needs to forget jargon and model in the business domain, not the IT domain. That is why we cannot rely on tool concepts. That is why I ban all from-code-to-services ideas.

And about reuse, that concept is wrong since it is an IT concept, not business one, thus theoretically not applicable to services.

Lastly, no one talks about versioning because there is not a decent implementation of it, although it may be great for lots of people if it was one.

Cheers!

William Martinez Pomares.

Re: Obituary? by Paul Korney

William, Thanks!
I often feel this idea falls on deaf ears nowadays, but it seems to me to be the whole point of SOA. It too often seems like we are developing a car with a bunch of engineers and product managers that never talk to the eventual owners and drivers of the product. I'm not meaning to say that business should control the technology used, but they certainly must be considered the principle value driver for any SOA effort. IMO, given this state-of-affairs, an SOA manifesto will only be of much value if it is at least somewhat intelligible to business stakeholders. When I read:
'A formal declaration of the principles, intentions and ambitions of service-orientation and the service-oriented architectural model.',
then I expect to see somewhere a clear statement of business customer value. A Frank Lloyd Wright quote that I like is (approximately):
'All architectural values are human values, else not valuable'.

Re: Obituary? by Jim Buckner

Jean-Jacques;
You mention SOA-RA, so I'm assuming that you understand the Business and technical ramifications described in the OASIS SOA-RA and perhaps you even contributed to the document.

Why don't you suggest to your constituents that they take what the SOA-RA says is the next step instead of waiting for the next great Manifesto?

The Reference Architecture suggests the next steps are to USE the SOA-RA models to derive a more Concrete architecture. A Concrete Architecture needs to be defined in a way that is appropriate for THEIR OWN organization's needs as specified by their local requirements.

The SOA-RA is abstract for a reason; to define requirements for a general solution that can be tailored to individual needs rather than specifying a single value solution for everyone regardless of their individual needs. Like defining a formula, and letting each situation fill in specific numbers to arrive at a solution that meets individual needs -- e.g. distance=rate*time.

The next step, after defining site-specific concrete architecture(s), is to build the technical platform necessary to realize the service-oriented implementation. And to set-up the governance necessary to manage and develop Services (also defined in the SOA-RA). Some basic capabilities (both business and technical) need to be in place before the developers can build and business can use services that meet the critical factors described in the OASIS SOA-RA -- allowing the business to use services with Effectiveness, Confidence, and Trust (goals defined by OASIS SOA-RA).

We need the RA because it describes the general Requirements for SOA -- without having to choose vendor driven Architecture (VDA), as described by ZapThink. Each organization needs to face making its own design choices as to how to implement the models and then to pick or build the platform that best suits their needs.

Understanding the RA will let them know what needs to be done on the Business Owner's side; what needs to be done by the SOA-Owner's side, and what the developer needs to adhere to during construction. This is all important for success - especially in the real world where different enterprises need to partner and participate -- and especially when your organization needs to contract for developer services or purchase "SOA" COTS packages.

You can't implement well constructed services by simply saying: "develop this business application using SOA", unless you specify what you mean by SOA. Therefore, the architects must define what THEY mean by SOA.

Having defined a concrete SOA Architecture and SOA technical requirements manual in the contract will allow the organization to map vendor and local developers' promises to required technical specifications. Otherwise, you get into a back-and-forth "yes it's SOA, No it's NOT!" argument that you can't win.

A manifesto will not solve the problem. Local sites need to start with a standard set of definitions and models; create their own implementation architecture and local site configuration and implementation requirements for their own and outsourced developers; and make sure that those meet the "Critical Factor" requirements described and modeled in the OASIS Reference Architecture.

Jim Buckner

Re: Obituary? by Jean-Jacques Dubray

Unfortunately a building has to stand on its foundations for a reasonable amount of time, or else architecture has no value at all. That's the problem of any solution architecture today, they cannot sustain the constant remodelling activities necessary to deliver the business value you are talking about. That sustainability has nothing to do with the business other than this is what the business wants. This is an IT problem. The SOA that vendors, tool vendors, analysts, pundits, standard working groups, REST-as-a-SOA, ... sell you, that SOA is just quick sand to sell more of the same old stuff. REST is the ultimate billable machine.

I will trust a group to produce something useful when they'll decide to:
- look at all that was done (including REST)
- sort out the pieces
- provide an articulation of these pieces
- decide what's missing
- package it in a human consumable way (no analysts needed)
...

If you want to do SOA (including REST) today there are so many things you need to do right that the probability of succeeding at SOA is close to zero (including with REST, again, show me the Enterprise Solutions that have been built in a RESTful way, until then the people that claim they can are no better are just the same kind of people as the pump & dump vendors and analysts).

Re: Obituary? by William Martinez

Ok.
... That's the problem of any solution architecture today, they cannot sustain the constant remodelling activities necessary to deliver the business value you are talking about. That sustainability has nothing to do with the business other than this is what the business wants.

That is a real problem. Still, we need to distinguish between changes due to IT, and those due to business. The IT ones should be refactorings, and no functionality is changed. Business ones are due to requirements variations, and those require more development, that I should hope is not much effort due to nicely implemented well defined principles.

This is an IT problem. The SOA that vendors, tool vendors, analysts, pundits, standard working groups, REST-as-a-SOA, ... sell you, that SOA is just quick sand to sell more of the same old stuff.

I couldn't say it better!. Totally agree. Most of the original products were repackaging in a stack of old technologies, some didn't even work well together (I had a case where the web service created by the wizard, was not able to understand the client created by that same wizard! God...).

REST is the ultimate billable machine.

REST is gaining fans, although most of them do not understand it well. Tools are seeing this boom and they are offering patches to sell, but as an addition (we support REST too!). Still, those features are far from being serious tools to create REST apps, they usually get to offer URI templates for instance. Most of them think REST is for creating services (which is not, didn't I say that before?).


If you want to do SOA (including REST) today there are so many things you need to do right that the probability of succeeding at SOA is close to zero (including with REST, again, show me the Enterprise Solutions that have been built in a RESTful way, until then the people that claim they can are no better are just the same kind of people as the pump & dump vendors and analysts).

If people thing SOA is the panacea, the cure for world starvation, and climate problems, they are wrong. As with any architecture, it depends on business, implementation strategy, quality properties, etc, that the architect should balance to decide which style to follow. So, SOA is not for everybody, and REST neither. And REST is not equal to SOA, they are for very different scenarios!

Question is, if anyone, has ever built a SOA or REST system as it should. I know the REST example is the web itself, although it has some parts that are not RESTfull indeed. Sometime ago I collected a series of wrong views people have about services and SOA, in my blog posts here and here. There I summarize how people understand Services and SOA, and how are they so wrong about it.

Cheers!

William Martinez Pomares.
Architect's Thoughts

Re: Obituary? by Jean-Jacques Dubray

William:

>> I know the REST example is the web itself, although it has some parts that are not RESTfull indeed.
The Web is a public content management system. It's really good at it and works well. People have extended this pCMS to deliver dynamic content and ultimately entire applications. It is not because the pCMS is RESTful that Enterprise Information Systems can be built in a RESTful way. Once people will show me an ERP or even a CRM implemented entirely with REST we'll talk again.

>>If people thing SOA is the panacea, the cure for world starvation, and climate problems, they are wrong.
Do not reverse the roles, this is what the RESTafarians are touting day in and day out.

The question, the only question is: Any solution architecture today cannot sustain the constant remodelling activities necessary to deliver the business value that is needed.

Until we will take a non religious approach to answering that question, but so many people have so much to lose that it is not surprising to see the level of confusion they generate. Again, until people will create a broad, honest view of the problem and the solutions that can be applied, we'll stay were we are.

Ultimately it is not SOA which is dying, it is IT.

Re: Obituary? by William Martinez

William:
>>If people thing SOA is the panacea, the cure for world starvation, and climate problems, they are wrong.
Do not reverse the roles, this is what the RESTafarians are touting day in and day out.

Please replace SOA with REST. The phrase is just as valid.


The question, the only question is: Any solution architecture today cannot sustain the constant remodelling activities necessary to deliver the business value that is needed.

Didn't get the question. That looks like an affirmative sentence. Anyway, I agree, but I would not say solution architecture, but actual solution implementation. If you show me a real SOA/REST based app, correctly implemented, that fails to deliver what the style says it will, then we have a problem with the style. If you show me a so called SOA that is just an Distributed Object app over HTTP, then I can point to you why it is not delivering. So, we can fix that, right?


Until we will take a non religious approach to answering that question, but so many people have so much to lose that it is not surprising to see the level of confusion they generate. Again, until people will create a broad, honest view of the problem and the solutions that can be applied, we'll stay were we are.

Meaning do not talk about believes, but about tested and proven developement that works. Good.
Ultimately it is not SOA which is dying, it is IT.

Sadly, I do agree with this.


William Martinez Pomares.
Architect's Thoughts

Re: Obituary? by Steve Ross-Talbot


The question, the only question is: Any solution architecture today cannot sustain the constant remodelling activities necessary to deliver the business value that is needed.

A very important observation. One of the things that SOA has suggested we get is higher flexibility. Of course that is not really true as it requires a great deal of though. Yes we get to reuse services and create composites and that is easier but it also can result in serious change management problems as we move further away from the core services. We had the same problems in RDBMS technology with views on views.

So the quest needs to be rephrased:

Wht are solution architecture today unable to sustain the constant remodelling activities necessary to deliver the business value that is needed when it is needed?

In part this is a timing issue and it is impacted by our ability to understand the change, model solution architectures in such a way as to quickly understand the impact of the change and then having tools to enable the change to be made very quickly. Some changes (like business rules) are very quick but need to be governed prior to production, some changes require re-wiring (like changing a BPEL process) which require management of versions over long running transactions and some are code.

The gap is really important - no wonder they say on the London tube "mind the gap". You might fall into it. So how can we understand the gap, the impact of change. Today solution architecture do not capture enough information and worst still they describe things at the wrong level to enable the information to be correctly captured.

TOGAF, IEEE, and other architectural standards and frameworks all claim it is a good idea that "an architecture be formally described" but of course none way how and the prevailing wisdom is driven by UML which does not really have the semantics at the right level to do it.

Somehow describing solution architectures at the right level needs to be achieved and it needs to be bound, as a separate step, to the underlying technology so we can ensure it continues to align deliver of the solution.

I have some ideas, as does Mark and these can be found in the Savara blogs at JBoss.

Re: Obituary? by Mark Little

Re: Obituary? by Jean-Jacques Dubray

Steve, Mark:

It's good we agree on the problem at stake.

I would like to emphasize, however, that we have done enough architecture, there is no need for more. We need a programming model that is architecture independent.

People need to understand that none of the programming models of a given architecture layer can become the programming model that can be used to describe solutions in an architecture independent way.

As long as people will focus on high level generalities (a la SOA-RM, RA, ML...), SOA will not be realized. SOA will be realized (and the value it can deliver) when a Service Oriented programming model will emerge. We have all the pieces, even some concepts of REST can be part of it. It is just a matter of putting all these pieces together. I certainly think that both of you are capable (and bold enough -I am just bold :-) to put it together. The question is will have the courage to do that? Will you go beyond vendor talk (tools or otherwise)? will you leave behind pump & dump analysts who understand nothing about SOA?

Re: Obituary? by William Martinez

Hello Steve, Mark.
From what you say I extract (correct me if wrong).
1. Failure to remodel in a timely fashion is because we are not able to understand the impact of change.
2. We are not able to understand the impact of change because our solution architecture is not prepared for it, or because it is not described at the right level.
3. Solution is then to describe it at a different level, and as another step, to bound it to technology.

Ok. I don't want to seem to simplistic, but presented like that it sounds as if the problem was a documentation one. Actually, you are right about understanding the actual nature of change, analyzing how that change is executed in business, and then provide the software architecture to allow that in a transparent way.

Let me tell you a story. I worked in a tool that was architectured to be expandable when I first saw it. At architecture level description, it was clear the reason of why, and a functionality was explicitly indicated to allow plugin of modules.
At design level, tactical, the designer added standard interfaces to allow new modules be added whenever they wanted it.
At coding level, operational, the interfaces were implemented, but the code was so wired inside, so coupled, that adding a new module required modifying the accepting code.

So, at architectural and design level it was all correct. At coding level the orders were accomplished, but the decisions at that level made the complete goal to fail. In that case, Should I change the architecture? Or should I rewrite the description? Actually no, what I did was modify the architectural process. That is, architectural work does not end with a document, as many people from the Agile world that I know think, it ends with the final code line written. So a process to actually evaluate the goals and principles at strategic level are being sustained at operational level had to be put in place.

That is an in-deep, vertical peer review. (BTW, a topic of a talk I proposed for QCon), where the whys and won'ts, including the impacts, are reviewed to assure the architecture is being built as it was conceived, or if the architecture has to change something due to implementation problems.

In the SOA case, I'm sure the problem of remodeling is not just because of architecture, but because of a bad solution for change decisions (modeling) and surely bad implementation. At the moment services are described as function calls, you have too much IT domain crawling into a service domain to be useful, is like hire wiring code into business. No wonder you are not able to change in an agile way.

That is the gap that we should close. So, be sure I will read the blogs to follow up the ideas. My take is architecture juggling with implementation description may mess up a little bit things, but a good process to be in-synch is a must.

Cheers!


William Martinez Pomares.
Architect's Thoughts

Re: Obituary? by Jean-Jacques Dubray

William:

the first step to build systems that can be easily changed is a versioning strategy that supports change without unnecessarily impacting software agents that don't need to be impacted. How often are you impacted when your banking services change? gmail? Hardly ever, even though they change all the time.

the second step is to have a programming model that is architecture independent. Obviously this programming model would be normalized (i.e. an element of business logic that physically needed to be deployed in several layers of the architecture is only defined once in the programming model). The mismatch between the programming models layers of an architecture compound the difficulty of changing by creating tremendous ripples across the entire stack.

Mark and Steve understand all this, the only question is will they have the courage to be the first ones to finally bring it to the level of visibility that will be transformational for our industry? Neither SOA-RM, RA or ML talk about versioning nor for instance they relate service interfaces to enterprise information model.

Our industry desperately needs these two things, again, Steve, Mark, all is in your hands.

Re: Obituary? by Steve Ross-Talbot

So Jean-Jacques, if you were to frame a principle or an intention (aspiration) what would you wish to say?

As you know way back when in the days of SpiritSoft we tamed the version beast with respect to CEP (aka SpiritINTELLECT). So I am aware of the issue and even more so in the embodiment of its need for long running processes in which change still happens but the lifecycle of the process remains current. Perhaps the best example is a life insurance policy or a long term bond in which the one thing you know is the the behavior of the product and therefore its computational model will change in flight.

Let me know your thoughts and I shall carry them with me.

Re: Obituary? by William Martinez

Ok.
Jean-Jacques, I see your main concern is that of versioning. Your take is to decouple the development model from architecture. Steve mentioned something about describing the architecture at the right level, which I took as lowering into tactical or operational level. I stated there are actually three levels, independent, but bound by the business goal, and that it is control process in development that will synchronize all that. So, there is a disagreement in all three versions.
BTW. The examples you mention may not use versioning at all, since they are complete deployments (clients in both cases are also changed).

Now, Steve. The versioning you mention may be similar to Jean-Jacques, or may be not. You are talking about Business Process Versioning. I think Jean-Jacques talks about it too, but then he mentions the developing model and that points to lower level versioning. Jar hell? Even that lower?

In any case, versioning should be taking into account. For lower level, it is an IT task. For BP level it should be a business task.

Back at the OMG technical meeting held this year here in Costa Rica, a friend of mine in a large bank had that same BP versioning problem for even year long running processes. It was asked to the BPM speakers and actually they didn't understand the problem since the response was about flexibility in change, but not about persisting current versions, deprecation, version identification, and all that stuff. Apparently, not tools nor consultants had those kinds of problems, so they didn't have answers.

So, as you see, it is not as simple as decoupling nor of focusing at one level. Jar Hell I can deal with OSGi (SOA again), CEP is yet another, more complicated beast. Developers look for solutions in tools. Other simply ignore the issue. I would be happy is at least it is accepted as an issue. Sad?

William Martinez.

Re: Obituary? by Steve Ross-Talbot

William,

I think if we can tie the versioning of a process to the underlying class and object loading then the platform can help us solve or at least manage the problem. The problem right now is that process descriptions do not carry such information as given, rather one has to do it. Even if the versioning and jar hell problem is resolved it still leaves us short because we then have the data migration problems to deal with too. So really you need the process to carry with it meta data that identifies changes to the underlying data and when the process is deployed for some distributed agents to carry out or identify the data changes needs ahead of process execution. The worst thing would be to have the process enacted and the data not up to the mark causing process failure at best and wrong results at worst.

I have added this stuff to my personal manifesto and Mark's to ensure we at least cover the problem. But the data one is a big one.

Re: Obituary? by William Martinez

Hello Steve.
Agree, still not so sure about the tie to classes, be careful that is not too coupling.

Agree too about data. But it is far more complicated. Data for processing can also be data needed to be persisted. And versioning implies keeping old format data, so metadata is not all that is needed. Also, if data schemas are migrated during long process execution, process needs to be sure it will keep the format it started with. So, versioning need to be even context level, still not isolated. That last one means that I would need to run statistics on all processes executed, and that analysis may require reading from different data formats and schemas.

Complicated? Yes, it is.

William Martinez.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

33 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT