Read part two.
What has the last year taught you about SOA? What did you learn that you didn't expect?
I don't know if I'd agree with the terms that it's awfully complex as a function. I would use the word multifaceted. Complexity assumes there's one face and that face is really complex. I think people perceive that complexity more because even though SOA has an A in it that theoretically stands for architecture, if I had gone back in time and re-invented the term – I'm not a marketing guy so obviously my terms are not as nice and crisp – I would have more called it service-oriented approach than service-oriented architecture. SOA has an architecture side it has a technology side, it also has an organizational side, it has a financial side. You kind of need to consider all of them.
CIOs these days have to consider all of them in order to really tackle the problem of SOA. It's not really one of those "I'll come in and install a new set of products that didn't exist before and voila I've solved this problem." B2B was an interesting experiment in trying to do that. It was a technology solution. SOA requires you to think across all of those facets, approaches, domains, in order to truly be able to implement it correctly. So sometimes people see the complexity because you have to be able to understand the technology. You have to understand how it applies vertically within the problem you're trying to solve in the business unit, as well as horizontally how does it impact my whole infrastructure and the way the company is dealing with its customers. It also requires CIOs to understand "Is there an organizational change I'm going to need to do to be able to deal with this?"How do you go about tackling something that big?
SOA is a very fractal type of deal. You start small and you build on top and you build on top, and every time you build on top it still looks the same, it just gets bigger and maybe has some different facets being exposed. So the whole concept of change management, the process that IT has been perfecting for years as the answer to chaos, would have to refigure it. Because now it's not about the big application lifecycle. Each application will have services and each one would have its own lifecycle. So going back to this fractal view, you can't say, "Oka,y you need a process that takes 50 days for how we move it from here to here. This guy signed that he fixed this. This guy signed that he tested it." It's now going to become a much faster rate of change.
So CIOs are seeing all of these and it's not that there's no answers, it's that CIOs want to feel that they really understand all of the problem domains to feel comfortable that they've really got SOA under control. I do think that SOA as a technology is implementing things so it will be much easier to build the app. It doesn't say it will be easier to figure out what the application needs to be from the business service perspective. It says from the deployment perspective, "I will let you build it in such a way that you can pick up components from a bucket and tailor them to the business requirements that you gave me, and in doing so I will create, compose, factor a new application."
The announcements we made yesterday on SOA 360, Workspace 360 and mSA [microService Architecture], these are the fractal and multifaceted approaches that we believe is necessary to make it happen. For SOA to be successful we believe you need to have a cohesive approach to how you pull all the pieces in the lifecycle together. This is our SOA 360 approach. How you take the creation, the development, the architecture, the deployment and the management all as an approach. You need to support that by a product set that fills those gaps. So Tuxedo and WebLogic for the creation and execution of Web services, or exposure of Web services in the case of Tuxedo, and then management capabilities and composition of the application with AquaLogic. To do this you're going to need an underlying architecture that is already scaleable and extendable, but now also is componentized and agile. So this is where mSA comes in with SOA, enabling our own applications. So when you're going into an agile deployment you no longer need a complex product set, you only need the pieces that you really need and you compose them together to create the environment you need to run on.
The other side of that is you need a way to expose that to the role players. So if you're a business user you need to work through a system to work this. If you're an architect, developer or IT person you need a system to work through. This is where Workspace 360 comes in where each one of those roles gets to see only what they need to see in terms of expertise. The contributed expertise as artifacts into the centralized location that is the AquaLogic enterprise repository, or Workspace Central. Each step is seamlessly connected to the step before through this centralized artifact repository. That's what Workspace 360 is. So, SOA 360 is an approach to the three product lines we have across the SOA lifecycle. mSA is the architecture that allows us to build products faster, as well as allow our customers to deploy those products in a much more composable approach. Then Workspace 360 allows each one of the roles to interact with this lifecycle based on what they know, and create and use only the artifact that they need, while all the artifacts integrate with each other in the center.