Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

Where Are the Clients In a SOA?


Stephen Beneteau is President and Senior Architect of UNIVOLV Process Mentors. He can be contacted at [email protected].


The best "enterprise architecture" plan will never be realized as long as developers assume the client of a piece of code is another piece of code. In reality, there are people creating code and by and large those people do not think of other people as clients. This is where SOA (service-oriented architectures) will fail.

The value of SOA is clear. We've been trying to produce SOA software for years. I know COBOL applications that were built on the same principles. I was a team lead for a project that built over 700 functional core services in a three-tiered architecture in COBOL 74; we produced code that was highly reusable. Of course, that was all in a silo for the large system we were building for a financial institution. We built it with the mindset that this software could be reused in other parts of the organization. I was proud of that work, but in retrospect, we weren't very good customers. We were happy to try to find commercial off-the-shelf applications that could provide major functionality, but we weren't good customers of code within our own organization. We didn't even look for software we could reuse from within the organization. The problem hasn't really changed today because we are still focused on the code, making it "reusable." The problem isn't really in the reusability of the code from the code perspective. We have to understand that the client of the code is literally other programmers and architects. We need to see ourselves as service providers who are creating code that needs to be right for our customers. It has to be easy to use. It has to be easy to find. It needs to be marketed and pitched right, and it has to fit the customer need, and we have to be better customers ourselves.

This idea of customer and service within the organization and team is very much not in the mainstream culture. Currently, our customers are perceived to be entities to which we have no real access or feedback. There are more people in our wider organizations to shield the customer from us than there are people in our development team. If I see myself as providing services to customers within my team and perhaps people in other teams within the organization, then I have to ask myself some questions that probably should be asked. If my customers can choose their service provider, and let's make no mistake, they are making those choices, what do I need to do to make sure I keep winning their business? How can I make my service as easy to consume as possible?

There are some great tools that are appearing on the market that support the consumption of reusable artifacts. These are collectively in the space of asset management. In the software industry, these tools can help provide some valuable metrics about the real consumption of reusable assets within their portfolio. We have generally not had this kind of information before. I'm trying to get some hard numbers from major players using these tools, but if I had to take a bet, I'd be trying to get a nice low number in the pool. So, if I'm right, then what is stopping the reuse of all our great reusable code?

As software developers we are not very good customers of the work our colleagues do. We are quicker to search the Internet for a utility or example than we are to search our own internal repositories. One reason might be that our organization has not provided a utility like a search tool the same way our web crawlers have. More importantly, we aren't thinking about other developers when we create the code. We don't create interfaces that make it easy for people to use our code in ways we have not considered. We don't provide design-level abstractions that help other programmers and architects fit our solution into theirs. We don't market the code to the rest of the team or to other teams within the organization. We don't do any market research to make sure the nontraditional customers of our code are going to make the most of it. We don't package it in ways that also make it easy to use outside our intended use.

The technological support for working this way is coming and parts of it are already here. We have to start shifting our focus toward service provision that is much more focused on people than on code to effectively make use of this technological support. Then we can use some of these cool tools to help market and make our code available to others. My hope then, is that we could see some metrics on reuse that really shows a valuable return on the long, hard work we have done trying to build reusable software. The customer focus shift has to come first. The service consumption in an SOA model is at least half of the equation.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.