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

There is no way I can see from the design that the Travel service will not need access to the Employee service in some way, shape or form. If they are operated in virtual isolation then you'll have a master data management issue just waiting to bite.

I've recently designed the architecture for a T&E system with the HR data within the corporate infrastructure and the T&E front end hosted as SaaS.

In that scenario the T&E system required a base level of HR data primarily to ensure that the employee was validated. It was also required to allow the system to correctly process travel bookings without requiring the employee to re-enter key data.

This was achieved by delivering the base employee data to the travel system, first as a bulk load and then through updates as employee data changed. This does require careful design as you are transporting some PII data but a secure transport protocol and good encryption between the source and destination mitigates for that.

Reporting on the travel bookings and activities are then entirely within the Travel system. They need to be held in a semi-warehouse state to ensure that changes in the base employee records don't pollute the historical travel records. These are 'transactions' and need to be stored as such.

With that in mind, while your design isn't exactly wrong, it's not exactly right. You are quickly going to hit issues that you need to revisit your design to resolve. My overarching recommendation would be to follow @le dorfier's advice and go back to the beginning. Design to meet all user requirements, make sure they are real requirements not just 'wants' (i.e. nice to have). The natural design will then include the requirements for not only the externally hosted front end but also the reporting required to satisfy the backend.

Virtually everything we design today has to be done so with interoperability in mind, we build modular software using components and patterns that deliver loose coupling. That flexibility saves us untold effort later and although it takes longer to design, it's so worth the effort.