XML Feeds
From Fax to SOA, a journey to success ?
We’ve come a long way since the days of fax machines and typewriters - the objectives have remained pretty similar, and with each iteration of the solution we’ve found resolution to issues in the former, yet we continue to unveil new aspects of the objective that need addressing. Will we ever get to a perfect solution ? What is a perfect solution ? Were any of the previous solutions wrong when they were implemented ? Or were they just right for the time ?
People argue, even today, about how much better previous methods were to those of today - ok, these people generally aren’t integration experts.. but they are people that use, need or implement integration solutions - and they far outnumber the ‘experts’. The most amusing examples are those that shout and stomp about costs, and threaten to go back to faxing their orders… yes, we actually had a customer threaten to do this because they didn’t like our (very competitive - we know we’ve done a lot of benchmarking) prices. In these cases a simple bit of math will help clarify things for them.. especially when they are a global business that has about 100 million B2B transactions (messages) a year. Shall we do the math ? Ah, go on…
100m orders with 5 minutes to read/type/correct each one, would take 8 hours a day, for 250 (working) days a year, for about 21 millenia for one person. Or you could hire 20,833 administrators, who could do this for you in one year (so they don’t get a pile up in their In Tray). At, let’s say, £15k per admin, that would be about £312m per year. Now, I can assure you that our entire budget for all of our customers integration solutions doesn’t come quite to that amount (I wish it did!). Suffice to say, this is where the discussion would end. (Oh, and let’s hope they don’t intend on posting those orders.. that would be another £25m just for the stamps). Of course, when we look at the entirety of all customers, and internal interactions we start to move away from the ‘millions’ and start looking at ‘billions’, which just makes the need for a strong automated integration foundation all the more clear.
Now, that’s an easy sell isn’t it ? Manual versus automated is dead easy - cost benefits are very obvious, even to the laymen. But what about more subtle changes in the design - ones which are really more technically focused, and yield more than just ‘cost reduction’.. for example, revenue opportunity and long term cost avoidance, as well as business agility and so on. That can be difficult - not for those who understand these things, but for those that hold the purse strings and let the black and red on their current years budget dictate their views. This is where we need to help them understand why these benefits will make their longevity in success a reality.
So… here’s an introduction for those that want to get to grips with how things have been progressing and, of course, why..
Simple Requirements
OK, so here are some diagramatic examples based on the following very simple set of requirements
- 1 Message Type (e.g. Orders)
- Content Consumers (e.g. Customers)
- Each using 3 Content Providers (e.g. Visibility, Warehousing, Finance etc)
The Manual Approach…
What Problems were Resolved by this Solution ?
- Sharing of Information with different parties to facilitate a common process/objective
What’s Good About This Approach ?
- Basic technology required
- Simple for small volumes
- Tried & Tested – provides a certain “Comfort Factor” through familiarity
- Human Involvement – more friendly, personal, and able to deal with highly complex decision processes
What’s Bad About this Approach ?
- Unreliable – Humans Make Mistakes
- Inefficient – Humans are Slow
- Inability to Scale for even moderately large volumes
- Lack of Flexibility – Training is expensive, therefore change is slow and unwelcome
- Complexity is high
- Resource Intensive
- Costly – Cost per unit is relatively very high
The Direct Point-to-Point Approach…
What Problems were Resolved by this Solution ?
- Automation of Processes leading to:
- Better accuracy and reliability
- Higher efficiency
What’s Good About This Approach ?
- Flexibility and choice of integration technologies
- Application Owner’s ‘Freedom’ and Ownership
- Tried & Tested – provides a certain “Comfort Factor” through familiarity
What’s Bad About this Approach ?
- Inability to easily scale for new requirements
- Lack of Flexibility – hardwired components demand dedicated support and knowledge, limiting options.
- Complexity is high – 18 components, managed by 6 different teams with 9 message flow configurations
- Costly – Support & Maintenance very high due to considerable overlap and duplication of effort
The Aggregated Point-To-Point Approach…
What Problems were Resolved by this Solution ?
- Reduction in Overheads and Duplicated Effort through Centralisation, enabling:
- Re-use of Intellectual Property and Knowledge
- Re-use of Resources & Personnel
- Simplification of Integration Solutions
What’s Good About This Approach ?
- Efficient Use of Resources (People)
- Centrally Managed, providing standardised management and operations
- Standardised Level of Service
- Single View of Systems Integration – reducing overall support overheads ‘investigating’ issues with multi-stage integration patterns
- Standardisation at the Application
What’s Bad About this Approach ?
- Complexity is moderately high – 9 components, managed by 1 team with 18 message flow configurations
- Complexity has been aggregated into a central point, rather than being resolved / simplified
- Static, difficult to change easily and quickly
The Information Oriented Approach…
What Problems were Resolved by this Solution ?
- Complexity of aggregated solution now simplified through standardisation of the information model
- Re-Usability (dynamic) and Flexibility now improved through standardisation
- Complexity is lower – 6 components, managed by 1 team with 9 message flow configurations
What’s Good About This Approach ?
- Re-Usability of Components in a Dynamic environment – “Plug & Play data”
- Standardisation of Content
- Abstraction done at the perimeter allowing internal functionality and features to be implemented once and function with all interfaces
- Faster Development Process when connecting to complex environments
- Standardisation at the Application
What’s Bad About this Approach ?
- Complexity of the interactions still not addressed – process control requires direct native service access, which can create business logic within the canonical adaptor (not preferred)
- Ability to easily change large functional areas of the enterprise still not available, albeit significantly better than previous approaches
The Service Oriented Approach…
What Problems were Resolved by this Solution ?
- Lack of Agility now resolved by abstraction of services into composite services
- Process Management & Control improved to provide more flexibility
What’s Good About This Approach ?
- Re-Usability of Components in a Dynamic environment – “Plug & Play data and services”
- Standardisation of Content and Functions
- Abstraction done at the perimeter allowing internal functionality and features to be implemented once and function with all interfaces
- Faster Development Process when connecting to complex environments
- Standardisation at the Application
- Agile, and able to change in line with business demand
- Better Visibility at the Business Process Level
What’s Bad About this Approach ?
- Can be complicated to build the framework
The Maturity Graph…
The Future Holds Untold Adventures…
Are you up for it ? Or would you prefer to spend the next 21 millenia manually entering order data ?
I know I would like to make things ‘just work’ - automatic integration of information, services, communities and, well, pretty much everything. But getting there will be a long journey, and not one stifled through lack of technical ability, but more by social acceptance and understanding.
Is SOA our end goal ? I doubt it. But it is our foreseeable path to success, and a stepping stone to better things. There are next steps, which I will continue to discuss here, but for now, let’s just try to get the majority of people to at least the 3rd or 4th step in this pathway to integration maturity… because like it or not, MOST ’solutions’ in existence today are in the first two steps..
Just in case you wanted to use this for your own integration discussions, here is a PowerPoint Show of the Evolution of Integration.
