Obviously Architecture has a key role to play in the tendering process. So starting with the Tender document – this is the specification for a solution. Much like policies and SLAs it is set of requirements and constraints many (all?) of which in turn realise the Architectural principles. So the categories of requirements and constraints in a tender look like this…
- Requirements and Constraints from existing policies and SLA/OLAs appropriate to the solution.
- Requirements and Constraints which will form the SLAs/OLAs for the new solutions.
- Functional requirements and constraints.
The first category will always exist, but categories 2 and 3 will vary depending on the extent to which the solution sought is a plug in replacement versus a solution for a new service.
I’m going to try this approach with the Role Based Access (RBAC) Project. This project aims to add Role Based Access functionality to an environment which already has an long established Identity Management service. Having talked and see demonstrated a number of RBAC solutions, we now have a fairly good idea of the art of possible and leads to two possible sets of tender requirements.
One set of requirements aims to augment the existing IM solution, the other replaces the existing IM solution. Several architectural principles comes in to play here: “Reuse”, “Single Master” and “Standardize”.
In the “Augment” model, the existing IM solution is reused and continues to deal with identities. However, unless the RBAC solution comes from the same supplier as the IM, we will end up with duplicate solutions in contravention of the “Standardize” principle. We also likely end up in contravention of the “Single Master” principle if we essentially have two identity databases which can’t be synchronised. Based on what we have discovered from suppliers this model can only result in the same supplier option. This assumes that the existing IM solution has been assessed against architectural principles and policies already and not found wanting. In our case, this is yet to be done as the Architecture Policies, OLAs, and SLAs are still being developed.
In the “Rip and Replace” model we start ticking the boxes if looking at the final solution as both IM and RBAC are the same system. But at what cost? We are “Ripping” out a complex system which connects to multiple other systems, having to pay for re-implementing the same workflows etc. So this solution could easily fail the “Viable” principle.
So we have an interesting conflict between procurements normal – “Tender to a set of requirements” and an architecture approach which has the ability to decide between two models based on alignment to principles and some initial quotes. Our procurement department has, in the past, tolerated single supplier purchases on the grounds of compatibility, but external financial polices limit this.