A Service-Oriented Architecture (SOA) is built incrementally. The process is both a journey and a migration. You start with a set of applications that inhabit an archipelago of systems—a set of application silos, each designed to meet the needs of a specific business application. Your destination is a computing environment that can be viewed as a single shared resource space, where the software components are either items of software infrastructure or loosely coupled business services that can be invoked as needed. And just to complicate matters, the business services may stretch out beyond the corporate resource space and connect to other computer environments in order to deliver yet more business services.
In siloed environments, users are defined in simple ways and identified more often than not through the act of logging in and providing a password. The identity they possess is a local one that provides local capabilities. However, a full-fledged SOA identity can’t be local because there is no “local.” There are services the user can or can’t use according to a set of permissions that have to be explicitly defined somewhere.
You don’t need to think about this for long before you realize that if you’re going to make the journey to SOA, you need to start thinking about identity management from the very beginning. It also will help if you think of identity management as a service rather than an application. Ideally, it should be a global identity service that users connect to when they enter the computing environment and which provides them with specific access rights to a variety of business capabilities.
The Adoption of Identity Management
Be warned. Just as the adoption of SOA is a long-term activity, so is the implementation of identity management. The destination is clear: to have a single automated service that securely defines every user, whether a member of staff, or working for a business partner or a customer of some kind, which securely provisions for them every capability they have or will be allocated.
Identity management is similar to SOA in one other respect. With SOA you start with what you have and gradually stir it all in, bit by bit, to run in a service-oriented manner. With identity management, you also start with what you have, which may be little more than the login capabilities of a multitude of systems and applications, or may include some password management, or could even extend to single sign-on.
Sophisticated or simple, it’s old technology, which deals only with access. It’s a long way from an identity management system that fundamentally links people to the services (business applications) and, possibly, to things (such as cell phones, laptops, and even parking spaces) that are provisioned to them. The identity management system reaches into the HR application, touches every software service a company runs, and stands as one of the foundations of IT security. Aside from its responsibilities within the enterprise, it also will be the source of any security credentials that reach beyond the enterprise.
It’s often difficult to justify building an identity management service in a strict cost/benefit manner, because most of the manual admin costs associated with identity management tasks are spread across the organization—activities that tend to occur when new staff join or leave, or reorganizations take place. Nevertheless, automating them makes a genuine difference, and such tasks will become much more troublesome and error-prone if they aren’t automated as SOA is introduced.
Although it’s rarely given much prominence, identity management is one of the pillars of SOA. With SOA you work toward building a computing environment where new business services can be quickly and incrementally added; however, you can’t reliably deploy such services unless you can easily provision them to the intended users and secure them. For this reason, when I’m hired to consult by companies that are moving to SOA, I frequently feel obliged to raise the topic of identity management.
