Configure, not code
Dave Linthicum had a great quote on his eBizQ blog:
Integration should be a configuration exercise, not a programming exercise, especially when considered in the context of a SOA.
While it may be true that some integration still needs to be programmed, we should be striving for configurable integration. As standards are adopted and incorporated into more and more systems, we can get there.
There’s a lot more to Dave’s statement, however. If you read between the lines, the message is that to really achieve the agility touted by the SOA pundits, the things that need to be touched when a business change occurs should be configured, not coded. Coding is a longer exercise than configuring, in most cases. In order to reach this goal, tools will need to continue to improve. At the same time, we can’t lose sight of the importance of testing. The promotion cycles associated with the deployment of a coded solution typically require extensive testing in order to enter an environment. In the case of a configuration change, that may not happen, but in the future, the impact could be catastrophic, as ZapThink analyst Jason Bloomberg called out in his ZapFlash, SOA Governance and the Butterfly Effect.
The point of all of this is that if you are an Enterprise Architect leading an adoption of SOA, you need to make sure that you’re making the appropriate things configurable, geared toward your operations staff, and using your developers for the most important things, developing business services.
6 Responses to “Configure, not code”
Leave a Reply
I´m just back from Gartner´s symposium in Barcelona. Talk about SOA was in many of the presentations. With some suggestions for SOA 2.0!
A presentation from IBM – who were heavily pushing SOA – added more confusion to this debate. They were presenting a SOA benefit as being that an end user could re-configure the steps of a business process on the fly.
I disagree.
At play here we have:- Coding, Configuration but also Workflow.
Yes SOA should bring the benefits of less coding and a move to more flexible config – but are we really suggesting that end users do config? What about the compliance and auditability issues?
If a business process needs to alter, an authorised config person would surely make the change? If in a specific occurrence of a business process – say processing an order – there needs to be some flexibility then that should be an allowable over-ride to a workflow and yes an end-user could do that.
When there is confusion over exactly what SOA is and is not – then it gets hard to convince businesses that they need to adopt it
There is a definite link between SOA and BPM/Workflow. That being said, the ability for an end user to tweak the process on the fly is far more marketing than it is reality. One of the points I make that is applicable regardless of who makes the change is the need for testing, and also governance.
As for what SOA is and isn’t, I’ve always been of the opinion that the approach to SOA and the goals you have in the short term and long term will vary widely by organization. I’ve never felt that BPM/Workflow and SOA were the same thing, however, I don’t see a way where an organization can be successful with BPM/Workflow without adopting the principles of SOA, as well. You can certainly adopt SOA without making any attempt to utilize BPM technologies. Business Process Analysis is needed for both.
I agree with you.
It is just a shame some big players in the market are confusing the picture.
If a business (rather than a technical) person comes away from an event thinking that SOA is all about an insurance clerk being able to tweak a business process on the fly – rather than a way to make their business systems more agile then that is a problem.
If SOA delivers on its promises it will enable IT departments to be able to reconfigure and more quickly deliver business process changes needed due to major policy decisions from the board. However execs are unlikely to sign off the investments needed if they think its about call centre staff bypassing the rules.
Hi,
I’m trying to get your RSS feed so I can link to posts and comments like these from your blog, but I’m getting an error. What gives?
Hmm… I just checked the feed with feedvalidator and it came up ok. I’ve contacted you via email with the RSS URI, which is: http://www.biske.com/blog/?feed=rss2. Feel free to contact me if you still have problems.
This has long been my position–I see SOA Change Time as being classified into three buckets, Configure, Compose and Customize.
Each bucket is 10x more expensive than the previous one–which suggests that agility, reuse and cost savings are the drivers behind configuration. Metadata configurational change is the key driver behind the business value at Sprint Nextel, a great SOA Case Study.
There’s a ton of attention on Business Process and Composite Applications when in fact Configuration and metadata based change time is lower hanging fruit. Good job pointing this out.
Miko