When to SOA or not to SOA is no longer a question
The concept of SOA has been along for a long time and originates from the IT side as a way to architect and design information systems. Recent years of initiatives to extend the enterprise information systems beyond firewalls out on the Internet and the need to expose and access functionality and content in legacy systems have made SOA to the dominating approach to IS architecture. Enterprises have come to realize that SOA is a necessity if their IT-based information systems are to be able to stretch out on the Internet – but also to quickly respond to rapid business changes.
Implementing SOA is however no guarantee that the IT systems will support the business as required by the business. Successful service orientation of a business and its information systems is tightly coupled to the ability to see the customers and respond to their needs. Regardless if the customer is internal or external to the enterprise, the customer is not interested in the service itself, but rather in the resources (informative content or other types of content) that it provides him with – and if and how they help him achieve his goals. Simply put, the customer does not consume the service itself; he consumes the outcome of the service.
Even thinking in terms of “services” might not be enough to be able to see and understand user needs. We must always remind ourselves that the services exist only to serve customer needs. Let’s take an example.
Physically handicapped people don’t have a need for wheel chairs. Their need is to move as freely and unhindered as possible despite their handicap. A wheel chair is a means helping them do that. But, there are other means too and someone will probably invent even better means than wheel chairs in the future. A product-oriented wheel chair manufacturer that does not understand the needs of their customers lacks the ability to innovate. When the innovation eventually comes, something that helps to satisfy the needs of their customers better than their wheel chairs, they would probably go on making their wheel chairs until they are either forced to change their business or put it down.
The point is that we must always define and design services in the light of real customer needs. That applies also for IS services in a service-oriented IS architecture. Otherwise, we might end up thinking that a service has its own reason for existence. That typically happens in engineering-minded businesses that develop products or services based on their own ideas rather than based on customer needs. They often end up asking themselves why their products aren’t as successful as they deserve to be and throw the hot potato over to the marketing department; “How can we convince the customer that he needs our product? “ In that stage, it is probably a little too late to tell the engineers to start all over and go to the customer to ask (or observe) him what he really needs.
Implementing SOA is however no guarantee that the IT systems will support the business as required by the business. Successful service orientation of a business and its information systems is tightly coupled to the ability to see the customers and respond to their needs. Regardless if the customer is internal or external to the enterprise, the customer is not interested in the service itself, but rather in the resources (informative content or other types of content) that it provides him with – and if and how they help him achieve his goals. Simply put, the customer does not consume the service itself; he consumes the outcome of the service.
Even thinking in terms of “services” might not be enough to be able to see and understand user needs. We must always remind ourselves that the services exist only to serve customer needs. Let’s take an example.
Physically handicapped people don’t have a need for wheel chairs. Their need is to move as freely and unhindered as possible despite their handicap. A wheel chair is a means helping them do that. But, there are other means too and someone will probably invent even better means than wheel chairs in the future. A product-oriented wheel chair manufacturer that does not understand the needs of their customers lacks the ability to innovate. When the innovation eventually comes, something that helps to satisfy the needs of their customers better than their wheel chairs, they would probably go on making their wheel chairs until they are either forced to change their business or put it down.
The point is that we must always define and design services in the light of real customer needs. That applies also for IS services in a service-oriented IS architecture. Otherwise, we might end up thinking that a service has its own reason for existence. That typically happens in engineering-minded businesses that develop products or services based on their own ideas rather than based on customer needs. They often end up asking themselves why their products aren’t as successful as they deserve to be and throw the hot potato over to the marketing department; “How can we convince the customer that he needs our product? “ In that stage, it is probably a little too late to tell the engineers to start all over and go to the customer to ask (or observe) him what he really needs.