By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
I would hope that we do see it in a standards organization, but there are many dynamics and it's hard to predict. So I'm keeping my fingers crossed. My view is policy addresses a layer of abstraction that the broad community hasn't quite come to agreement on. So I think it will take us some time. If you look at the lower levels of the stack, it took us a while to reach consensus and agreement. Policy is moving towards the higher levels. So maybe it's okay to not rush into and get something out there that we have to come back and redo later. I would hope that we get it right together.
There is nothing in particular I would call out, but if I put my architect hat on, I believe in simplicity and consistency and being able to use just what you need. Some of the concerns out there may be looking at the broad spectrum. Instead focus on what it is that you need and what gives you value and don't expect that you're going to use every feature and every aspect of these specifications. Do you see any open source opportunities for Microsoft in the upcoming year?
On the larger open source side, there are multiple dimensions. There is the development model, there are the philosophies, there are the licensing schemes and then, lastly, there are the business models. First and foremost we think of open source as being a development model around the idea of community. If you look at our work with VS.NET 2003, you can see that we've been learning from the community about the benefits of deeper collaboration. Even the notion of community technology previews where we rev these previews out to the community so we get feedback on them, we are leveraging those aspects.
I would also call out the Shared Source Initiative as probably being the manifestation of our interest and our response in terms of the open source community.What are your thoughts on Service Component Architecture?
I see SCA as being more of a reaction to the heavyweight nature of J2EE and the big container model. I see SCA as being more of an acknowledgment of the lightweight models like Spring. Certainly if you look at our container models going back, the lightweight nature of the container model is something we've been able to do for a very long time. I think from a mindset perspective, SCA is more of the community walking away from J2EE and the complexity and coming more into our view of the world. Is XML-based development key to cutting down on complexity?
I believe in loose coupling. I believe in simplicity. I think what XML has given us is the ability to connect, to communicate. It's really been the linchpin of service-orientation. We talk about services as though they are abstract things, but I think we have to agree that the success of service orientation has certainly been due to things like XML and SOAP, so from that perspective I would certainly agree with that. Are there any particular tools you think will drive more users into a loosely coupled mindset?
I think the key is going to be using models. And again, not using single-language models like UML, but using domain-specific models – models for the developers, models for the architects to address the business requirements, models for the infrastructure architects to map and design onto the operation infrastructure. I believe that is going to be the place where we can truly realize the ability to map from the business requirements down to the operations. There are other things that will happen, but in my view they are much less interesting and important. Are we hitting a point where the SOA light is going on for a lot of users?
In some ways I think it already has. There are customers who are having extraordinary success with service orientation. However, the customers that are being truly successful are those that have business value as the higher element. The customers that I see struggling with service orientation are those who put IT first or who put architecture first. I lead the architecture team at Microsoft, but I will be the first to tell you that architecture is not the end goal. Customers don't want SOA. Customers want business value. For service orientation to create business value, it has to exploit new business opportunities. Being more agile, that's the value. I have a hard time when customers tell me we have this maturity model for SOA, because the endgame is not how sophisticated or how complex or how elegant your architecture is, the endgame is tell me what business value you created. What do you think is coming in 2006 that many people don't expect at this moment?
One is that service orientation as a mindset will be pervasive, I think it will be something that we take for granted. I'm hoping there will be a walking away from this idea that SOA is the end goal, but to me the more important thing is the notion of service consumption will be the higher order. I think that is what '06 will be known for.
I believe that there's a place for the XML hardware. Yet if you remember the late '90s back in the dot-com days, there was this surge in interest in these Web accelerators and people were talking about how the hardware would take over, essentially, the processing of transactions. I don't think that is the higher order aspect. I think software is the higher aspect. What SOA pitfalls do adopters need to avoid?
People think SOA and they think services. Well, meaningful services own data. There's a lack of awareness of the impact that data plays in building these connected systems. I wish they'd give more thought to the data behind the service. The second I would call out is that factoring services is critical to success. There was this time I was talking to an ISV, they had taken this monolithic system and redesigned it to be service oriented. They have about 19 services and what was happening was, in the middle tier, they were basically making all these requests to a dozen or more services for every business transaction and the middle tier was doing all this mashing and mixing of the data. In reality they had a system that was much less manageable, much less useful. I would hope that architects and developers think very hard about service factoring. A service is not a business object. It's not a business component. A service is a much larger abstraction and it owns data.
This article originally appeared on SearchWebServices.com.