Function Point Inflation

The central problem I'm trying to solve is to apply a sizing metric to Integration style software projects. The kinds were we take one proprietary format and transform it to another format. For example, take an XML sales order request from a website, turn it into a SAP RFC ORDERS05 document and then the response back to the client from RFC to XML. My company does a lot of work like this.

After reading the David(s) book I was really left none the wiser about how to apply FP to this work. I accidentally joined the IFPUG thinking I needed to be a member to read the mail forums. Turns out the forums are public. In any case there are quite a few postings on "middleware" and even a few on "eai". I've read them all but still left with no clear feeling on this. The best posting I read was posted almost 3 years ago.

Additionally, the IFPUG has some guidance on counting middleware applications in a paper titled "Hints to Counting Middle-ware Applications" available to members. I found this whitepaper only mildly illuminating. The problem I had with a lot of these resources is the inclusive definition of "middleware". Basically, middleware is defined as anything that sits between an endUser application and the datastore. So a database driver is middleware, an OS is middleware, an EAI transformation and routing engine is also middleware. From a purely architectural standpoint this is true, but there is a vast difference between an eai transformation engine and an OS.

So, what I've done is composed a couple of common EAI scenarios and pointed out how I intend to count them. I've posted a message to the IFPUG mailing list to garner comments on this post. I hope the discussion continues either here or there.

The scenarios are designed to build upon each other in complexity and to exemplify the common things you might do with an eai engine. To give these scenarios "new-technology" polish [circa Oct '05] , you can visualise the scenarios as executing on an ESB to realise an SOA. Or you could just call it eai.

I hope you can understand my diagrams.

Scenario 1 - A simple XML input is posted to a legacy system

In this scenario an endUser application posts an XML document to the EAI server. From the EAI's point of view, this is an External Input. The inputXML is transformed to a canonical format which is considered an ILF. The ILF is never persisted but I count it so because the "hints to counting middleware" paper lets me. From the canonical the data is transformed into SAP RFC format and finally leaves the EAI system as an External Output.

The reason why I've broken it up into an EI and an EO will be explained in scenario 4.

Any comments on this?

Scenario 2 - an enrichment

Lets go back to scenario 1, and introduce data enrichment as part of the first transformation step. It's often a requirement that you need to lookup some value before passing it onto the backend. For example mapping zip to suburb or somesuch. This enrichment process I have chosen to model as an EIF. In most cases, this EIF will be a simple EIF because you often get only 1 or 2 fields.

Is this the correct way of thinking about this functionality? Or should I count this an EQ?

Scenario 3 - a simple xml request/response pair

Is the same as scenario 1 and we've lost the enrichment, but there is a response sent back to the endUser application. This essentially duplicates the FP count.

scenario 4 - addition of another endUser appplication

Scenario 4 illustrates why it's important to count the input and output as different constructs. Initially, I thought it would be adequate to count a single flow through the eai layer as an EO, but then it wouldn't allow me to count additional end user applications distinctly. Consider the fact that this addition comes at another time, so in some sense it's an enhancement. I want to count that fact that I only need to half of the work I previously did. In this scenario userAppB means there is an additional EI and EO that needs to be counted.

Is this the best way of going about this?

Conclusion
So, in conclusion, do experienced FP counters have any issues with this? My goal is not to compare across companies, but establish some kind of model within our delivery group.

the function point discussion can be found here

eai function points estimation

Comments

[Danesh]

Hi -
I have linked this post at
http://dan8sh.blogspot.com/2005/11/estimating-development-effort-in-eai.html

[Myhael]

Hi,
I think the classical fp are not applicable or
at most partially applicable to EAI.

The main reason is that FP are dependent
on the development methodology you apply,
in this case FP, imho, are correlated to
a Yourdon/DeMarco approach.

The Yourdon/DeMarco is a data-driven
methodology and is applicable when
you build data-driven _applications_.

EAI is not an application, but a piece of infrastructure.

If you go to http://www.integrationpatterns.com/
you will see that application patterns and
integration patterns are two very different things.
Also you may search the internet about the
applicability of FP to the Jackson methodology
or to any object oriented methodology and
you will find that you must bring significant
modifications to the way in which FP are applied.