ThouShaltIntegrateByTheSweatOfThyBrow

Overlap and duplication can be a problem and costs a lot to maintain (data, business rules, mappings, ...)
In theory good architecture could emerge, but human factors and incentives often mean it doesn't.
When responsibility is devolved, people have to accept the responsibility.
Who pays for "harvesting" from existing artefacts? Harvested components add a lot of complexity. Early adopters will tend to pay the premium needed to implement the approach (e.g. the first team who want to reuse something need to pay to make it generic).
Requires collective ownership and responsibility over the whole (which often doesn't happen).
CV driven development may mean that there is fragmentation across the systems.
Risk of divergence of important aspects of integration like business rules.
There is a duty of care to "downstream" stakeholders who may not have funding or political power.

GPU points ...

Data structure often considered in isolation without considering (for example) messaging, constraints, rules, coreography ...
Central database needed in conjunction with schema for reference data (so who owns it, maintains it, pays for it, ensures data quality, ...)
Removes burden of a lot of basic validation at system boundaries (use schema validation).
Need good channels and forums for communication.
Changes to central schema can have a "ripple" effect if versioning is not carefully managed.
Central architecture team doesn't have system specific knowledge and so may design inappropriate shared schemas.
No real incentive for any of the system teams to make the process work.

EPS points ...

Information flow, exceptions and business process must be considered in conjunction with the structure.
Need strong architecture function to counterbalance powerful system teams.
IDs need to be carefully managed and mapped.
Central infrastructure is hard to scale, make resilient, ... becomes major point of failure.
Business process concepts need to be carefully designed.
Process of central schema change is critical to make the approach work.
Need a lot of examples as well as definitions.

ECM points ...

Inconsistencies and missing information cause major delays.
To make this successful, need a strong central architecture function.
Not clear what the value of the central schema is. Underspecification and flexibility caused problems.
Disagreement over the value.

Just do it approach:

Duplication of effort across mappings, reference data management etc.
No common understanding of domain developed across teams.
If the GPU changes then there's a nasty ripple effect where all of the feeds into it change.

Central schema approach:

Schema is not enough and you need process, constraints and reference data solved.
The change process is critical:
General mutual agreement is needed;
Schema must be designed to allow change (e.g. xs:any, allow for partial schemas)
Manage versions carefully.
Allow for multiple releases in production.

It's not just about the structure, stupid!

[Back to SpaTwoThousandAndEightOutput]

Contents