Information Technology Reference
In-Depth Information
What “tight integration” means in practice is that products only play well
with others from the same stable. Many of them have proprietary “hooks”
into complementary products even when open protocols would suffice. We
know of one vendor whose interceptor component would only work in
conjunction with their own policy/rules engine, which in turn was dependent
on their specialised directory server. It was impossible to deploy one
component without deploying at least two others, and interoperability with
competing products was out of the question. This happens to a greater or
lesser extent with all commercial vendors. It's part of their competitive DNA.
Vendor lock-in also leads to a higher TCO (i.e., ongoing and switching costs,
even if not up-front costs).
Conclusion
: The combination of high upfront licence and consultancy fees,
the tight coupling between components that complicates roll-outs and rules
out incremental funding, the complexity of the product (impacting its
understandability and maintainability), its impractical centralised model, the
necessary customisations you need to make and the possibility of being
locked into a particular vendor, contrasted with the simplicity of data design
that can facilitate robust integration and the availability of a significant
subset of IAM capability at commodity prices, should give you pause.
Well, this paper offers a much more attractive alternative. Our prescribed
approach is simple:
1.
Use the venerable architectural principle of “High Cohesion, Low
Coupling” to identify the core functional components of an IAM system.
Design loosely-coupled interfaces between them, often based on just
data elements. Economy and agility follow from this principle.
2.
Use Open Source components to deliver commoditised functionality
(we'll name some good products you can use). There are many
organisations that provide commercial support for these products for a
reasonable annual fee, if you don't want to do it yourself.
3.
You may find that the functionality gap to the simplest system that
meets your requirements is quite bridgeable. Many of these
requirements are necessarily specific to your organisation and we would
be no better at predicting these than the big IAM vendors. So rather
than hack an unfamiliar product to deliver that functionality, build it in
the simplest way possible, using the tools your in-house developers
know best. This is cheaper than using vendor consultants, maintenance
is easier, and upgrades are on your own schedule with no artificial
dependencies. We will identify some likely data structures and
