Calculating the ROI of EII: Application Maintenance (Example 5/5)

Because the EII layer can easily handle additions or changes to underlying data sources, organizations can focus on maintaining the EII layer and not the maintenance of every application and its connection. If a data source changes, the administrator only needs to update the mapping in the EII layer; all reports remain unchanged as they use the schema defined in the EII layer.

To figure out if this can save you money, think about this question: How much does it cost to maintain point-to-point connections among all your applications and data sources?

                                                                                         

	Example	Formula
Conventional   Approach
Cost to   develop a customized connector between two applications ($)	$10,000	A
Number of   connections required per year	25	B
Application   maintenance cost using conventional approach ($)	$250,000	A * B
Cost to change   a report because a data source changes ($)	$1,000	C
Number of   changes to reports required per year	200	D
Application   maintenance cost using conventional approach ($)	$200,000	C * D
EII   Approach
Cost to   develop a customized connector between two applications ($)	$0	E
Cost to change   a report because a data source changes ($)	$0	F
Cost to change   a data source mapping in the EII layer ($)	$100	G
Number of   changes to reports required per year	200	D
Application   maintenance cost using EII approach ($)	$20,000	G * D
Potential annual   cost savings from EII ($)	$430,000	(A * B) + (C *   D) - (G * D)

In this example, a company that eliminates customized programming for connecting applications and changing reports will save $430,000 by using EII.

• What value-add projects could your IT team complete if they are not changing report formats?
• How much more motivated would your developers be if they spent less time on software maintenance?

That concludes our five-part analysis.  Hopefully you've found some areas where there might be cost savings.  If you did and would like to take things further, here are some suggestions:

1. If you want to use your own numbers in the above examples, you can request the companion Excel spreadsheet from Ipedo.
2. If your business situation requires a customized financial model, one of our analysts can provide assistance with the process, or even build an interactive spreadsheet based on information that you provide.
3.  Once you complete your financial models and convince your team that EII looks good on paper, a logical next step is to develop a proof-of-concept application that demonstrates cost savings and/or productivity improvement in a controlled environment. Ipedo can help with this as part of the sales process.

EII Haiku

In high technology, we often do things that have never been tried before.  I'm fairly certain this is one of them. 

Since I was recently accused of being too serious with my ROI posts, but not wanting to give way to the senseless prattling of many blogs, I offer you EII Haiku.  I like to think of them as lighthearted but deep.  Enjoy.

Queries federated
Distant rows and columns meet
My warehouse unscathed

Web Services, SOAP
Loosely coupled, lightly known
Join them, EII

Data is scattered
Metadata, SQL meet
All becomes as one

P.S. - If you would like to share your own, please feel free to do so in the Comments section.

"Data Driving SOA." Amen, Brother.

I was pleased to see Ronan Bradley's post from the other day 'Data: The Heart of SOA.'  I liked it so much I almost stole the title.  In it, he talks about how data issues really are part and parcel of any SOA project.  Amen, brother.

Once SOA projects get beyond simple 'Hello world' examples, data becomes critical.  First, you need something to pump into the service.  Then, of course, you need to make sure the data is correct.  So while much of the talk has been on service-enabling applications, this is all meaningless unless you can service-enable the data.  People in the data integration space like to refer to these as 'Data Web Services' as opposed to 'Application Web Services,' and often just 'Data Services' for short.

The keys here are data models and data access.  Data models allow you to know what the data looks like, what it means, and who owns it.  Data access is just what it says it is, but involves performance and security (and maybe even governance) issues.

I recently wrote about how EII is perfect for creating data services from existing sources - it provides the mediation layer to address performance, security and governance concerns.  To Ronan's point, Ipedo's product also allows the dynamic creation of data services from existing data models:

What's even cooler with Ipedo's product is that all of this can be scripted.  As my colleague Peter Spielvogel wrote about in The EII Files, Ipedo can automatically import data models from popular modeling tools like ERwin and ER/Studio.  So you can import all of the data models you need in a matter of minutes.  Once in Ipedo, you can script which Views you would like to be made available as Web Services, and voila!

I think we'll see more and more companies looking for ways to leverage their existing data models, which are typically relational, and transform them to Data Services. 

Dave Linthicum in his post "'SOA is Data' Really?" takes issue with Ronan's emphasis on data over process.  While I don't dispute that process and functions are the focus of an SOA application, a few things seem clear.  First, data services can support application services (get me customer data, get me risk profile, get me consolidated sales figures, etc.).  Second, many Web Services really are just data services, allowing easy access to information.  Third, seems to me that RESTful Web Services, being gets and puts, are predominantly Data Services by their nature.

That said, I also think you'll see more and more use of EII within ESBs, where ESBs will call a Data Service that is mediated by an EII product.  EII servers are just better suited to this task.  So the process- or application-oriented bus products can do what they do best.

Can I get an Amen?

EII and the Bus

A picture is worth a thousand words, as they say.  Based on all the words that have been written about ESB, I'd say the picture below is worth even more.

Bill Inmon had the following picture of why a bus is not an integration panacea is his recent B-Eye Network article The Bus as a Substitute for Integration, Part I:

Now you could read the article, but this picture sums it up, doesn't it?  That's how it struck me.  Creating a powerful, yet simple, picture of a complex issue is hard, and takes a foundation of expertise in a topic area, and still then some sweating over. (For some great examples of excellence in infographics, I highly recommend The Visual Display of Quantitative Information, with my favorite Napoleon's March chart.)

Bill Inmon certainly knows a thing or two about data integration, which is perhaps why this picture is so poignant.  And while it is not about EII per se, it reminded me of many conversations I've had with ESB proponents over the past year.  The point I always try to impress on people is that ESBs are good at reliably moving data, and they are (thankfully) more open than some of the older bus technologies, but they still don't help you integrate the data.  The reply to which - and I always love this one - is "All you need to do is write some code..."  If I had a dollar for every time I heard that one...

Here's a better alternative.  Create a parameterized View of what you want in an EII product like Ipedo's.  A View is essentially a virtual representation of the data you want, joined, cleaned, and - importantly - semantically correct.  Then, instead of the typical bus flow of Get A [invoke custom code] then Get B [invoke custom code] then Get C [invoke custom code] and so on, the View queries multiple data sources and returns the information your application needs to the bus.  It's not magic, just a cleaner, easier approach with a more suitable tool.

So before you jump on the bus bandwagon, take another look at that picture and think about how EII can help.