Some Definitions
Without first providing these definitions, everything below will be confusing:
-
Service Oriented Architecture – I will use this term to describe a technical architecture for software development and tool implementations within an IT infrastructure that makes heavy use of loosely coupled and message based integrations between systems.
-
Service Provider – An organization that is responsible for providing IT services (hosting, network, applications, etc…) to other organizations.
The Concept and Relevant Standards
For the past year or so, I have been doing allot of thinking about developing a markup language for service providers (managed, security, application, etc…). The idea was to have a set of schemas that would extend markup standards beyond the base
Data Center Markup Language (DCML) by representing some of the common elements of a service provider’s environment and tools. Some of the functional areas that I was interested in including were technology specific (such as DNS, SNMP, Network Device Configurations, etc…). The other functional areas that I was considering were more specific to a service provider’s environment than the requirements of the more general data center. These included the ability to: represent complex customer relationships between the service provider and customers themselves; interact with other service providers as partners, vendors or customers; and provide reasonable levels of transparency within the service provider’s environment.
As I spent my time thinking about this, it turned out that the DCML group was being integrated into the
Organization for the Advancement of Structured Information Standards (OASIS) and the group’s work was expanding to accommodate some of the concepts that I was looking to have modeled. Specifically, the group expanded to include technical committees focused on
applications and services,
networks,
servers, and
provisioning. While there are still many service-provider oriented information domains that I believe the standards organizations should be working on the models for, this shows that the industry is headed in the right direction.
Implementing Something Now!
Regardless of the advancement of these standards, we are a long way away from being able to actually implement some of these concepts within a real service provider’s infrastructure. My new goal is to find ways that I can implement a service oriented architecture within the environment that I work in on a daily basis.
Although I don’t have a formal requirement set for this initiative, the basic functional decomposition of the requirements includes the following domains:
- Service Provisioning
- Service Transparency
- Service Quality Assurance
- Utility Functions
The
service provisioning domain represents the set of services that support automated provisioning of any tool or service within the service provider’s environment. This includes services such as monitoring, DNS, network configurations, user accounts, etc…
The
service transparency domain includes the services required to provide customers with the ability to view information about and, in some cases, interact with the environment that their services are being provided from. The transparency can come in forms as simple as read access to the CMDB elements owned by a customer or as complex as allowing the customer to execute commands on those same CMDB elements.
The
service quality assurance domain includes functionality that helps make service delivery a “closed loop” environment. The domain is focused on providing access to each element of the infrastructure used to provide customers with each contracted service. The “closed loop” functionality is developed based on using these services to reconcile each infrastructure item with the expected state.
Lastly, the
utility functions domain includes functionality that is more general in nature. This includes items like authentication and authorization data sources, user ID and password generation tools, common logging mechanisms, etc… Together, these domains are meant as a starting point for an actual implementation of a SOA with our environment.
Each of these domains is represented by at least one initial project that we have ongoing. I will write more about the domains and the associated projects in a later post.
