The Agility issue

A previous post comment, was the inspiration for setting this subject. Actually, the issue described was fuzzing me in the past. The content is agility. Agile with the wide notion of the term and not bided into the for-come notion of agile development, projecting and so on.

In almost all projects related with software development, my main issue was the ability to be as more agile as possible. Not only from the technological perspective but also from the managerial and marketing orientation that any complete work needs to fulfil. Meaning that expect from the agility to use yours favourite, loving soft tools kits etc (ability which comes usually afterwards in a second time), you might have to establish a prospect relation with customer, cooperators and sell thyself ;) . Of coarse all these when you are not part of a big company or organisation which either has an establish name and image or has the proper persons for doing that.
The above approach (correct or not) was (and is) always tingle me when trying propose a work to be done. Especially in the past years, whereas the open source wasn't so approved from the clients. Agility but moreover stability and reliability were (and are) the main issues that make clients sceptics about thinking on open source. Of coarse, the budgeting and real agility issues were the real allies. And all the above for the small to middle clients (which are the majority in my cases).

For the cases whereas you want to use/build SOA applications, you have to start considering the parts which will make your life easier.

(a)ESB-ing

The Enterprise Service Bus (ESB)- which can be defined as middlewarethat brings together both integration technologies and runtime servicesto make business services widely available for reuse - offers the bestsolution for meeting today's enterprise application integrationchallenges by providing a software infrastructure that enables SOA.However, there are currently a number of different vendors that provideESB solutions, some of which focus purely on SOAP/HTTP and others whoprovide multi-protocol capabilities. Because these vendors span thehorizon from big enterprise generalists (app servers), to mid-tierenterprise integration providers, all the way to smaller,ESB/integration specific-providers; there doesn't seem to be anestablished consensus regarding the key requirements for an ESB.

As application architects, we have often thought about whatrequirements would define an ESB designed specifically to cater to theneeds of an agile, enterprise integration model.

... main characteristics of an Agile ESB

The main criteria we were looking for in our ESB are as follows:

1. Standards based

While standards-based support is marketed by many ESB vendors, thesupport is provided externally, requiring developers to work withproprietary APIs when directly interacting with internal APIs.A good example is ServiceMix was designed with the requirement to eliminate product APIlock-in, by being built from the ground up to support the Java BusinessIntegration specification (JSR 208). Our agile ESB needs to use JBI asa first class citizen, but also support POJO deployment for ease of useand testing.

2. Flexible

Another characteristic of an agile ESB is the flexibility with whichit can be deployed within enterprise application integration framework:standalone, embedded in an application component, or as part of theservices supported by an application server. This allows for componentre-use throughout the enterprise. For example, the binding for areal-time data feed might be aggregated as a web-service running withinan application server, or streamed directly into a fat client on atraders desk. An agile ESB should be able to run both types ofconfigurations seamlessly.

To provide rapid prototyping, an agile ESB should support both scripting languages and embedded rule engines, allowing businessprocesses to be modeled and deployed quickly.

3. Reliable

Our ESB needs to handle network outages and system failures and tobe able to reroute message flows and requests to circumvent failures.

4. Breadth of Connectivity

An agile ESB must support both two way reliable Web-services andMessage Oriented-Middleware and needs to co-operate seamlessly with EISand custom components, such as batch files.

Having the above in mind, the steping described on the getting-started post, will give the ability that the requirements constrains define, to have tool-ing freedom and open source approaches. For example it will be nice to be able to have an ESB to be vendor independent and open source,in order to promote user control of source code and direction. An added benefitof this is not only the zero purchase cost, but the total cost ofownership will be reduced where users are actively contributing andmaintaining our ESB. Making therefore, a possible quick -win be more realisable.

Furtheremore, the constrains and the business needs will provide the guidance for using other associated tools in order to develop and implement the necessary parts for web services, pojos, etc. The tooling know goes one step further to what can fit in the scheme proposed by the solution. And this is the reason that in the post comment i mention about seperation of 'concerns' meaning an agile seperation in order to extend the scope of freedom in the tool-ing adjenta available.