Dr. Dobb's Journal - April 2008 - (Page 10)

D04vox_p2as 2/13/08 11:33 AM Page 10 Alia Vox by Stephen Beneteau Where Are the Clients In a SOA? 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 threetiered 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. DDJ Stephen Beneteau is President and Senior Architect of UNIVOLV Process Mentors. He can be contacted at beneteau@univolv.com. 10 What is stopping the reuse of all our great reusable code? Dr. Dobb’s Journal l www.ddj.com l April 2008 http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - April 2008

Dr. Dobb's Journal - April 2008 Contents Hmmmm Alia Vox Developer Diaries Dr. Dobb's Excellence in Programming Award Conversations Fast String Search on Multicore Processors The Byzantine Generals Problem Optimizing Math-Intensive Applications with Fixed-Point Arithmetic Random Numbers in a Range Using Generic Programming The Agile Edge Effective Concurrency Swaine's Flames

Dr. Dobb's Journal - April 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.