Reports in SOA (Business Intelligence & Service Oriented Architecture)

Question

I have SOA with a Employee service and a Travel Service. The travel service will create a travelID entry for the employeeId in the [Travel] database. The employee will be u

Answer 1

This is a good example of the kind of confusion that can result when you aren't clear about your design priorities. And in particular, for my taste, there is too much concern with the technical issues and not enough with the user requirements.

I would start out by working with the stakeholders to build a good set of user stories sufficient to identify the scope of the project, and to list the capabilities that will be used for a first phase acceptance test. Your chances for a successful project, and for reducing the likelihood for redesign later, is to agree on a description for a complete deliverable that is immediately useful and provides obvious value once the first phase is complete.

It should be composed entirely from the user's point of view, without even using the words "database", "SOA", "web service", "API", etc.

What you will be building will be a kind of contract agreement between you and the customer for a service of value to them; and once it's agreed, it shouldn't change except to increase its value to the customer in his/her terms. So your best bet is to try to defer consideration of the "how" issues until you have the "what" firmly nailed down.

Then you'll have the freedom to consider various technical options that might be used to deiiver the same result. Often there's a phase-one design that just provides enough to make it work; and you want to preserve the flexibility to learn and adjust the back end in any way you see fit as long as the conceptual contract/logical design is unchanged.

In my experience everyone will be happier if you put your first attention on being able to react to user expectations (which will fill out as everyone learns from the process) rather than pre-optimizing the technology. Microsoft gives you lots of ways to mix and match and evolve an enterprise design. If you're into Agile, remember to start with the least development that works and then iterate like mad.