I had the pleasure to moderate a panel of BriefingsDirect SOA Insights Edition regulars and guests at the recent the Open Group’s Enterprise Architecture Practitioners Conference in Austin, Texas.
The topic was "The Future of SOA," and the panel really rose to the occasion -- from BPEL4People to semantics issues to what ultimately constitutes SOA success.
The live panel consisted of Eric Knorr, executive editor-at-large at InfoWorld; Tony Baer, principal at onStrategies; Todd Biske, principal architect at MomentumSI, and, Beth Gold-Bernstein, vice president of ebizQ Learning Center.
Here are some excerpts:
Dave Linthicum anticipates that, in as few as five years, the role of enterprise architect and the role of SOA architect will meld.Read the full transcript for more IT analysis and SOA insights. Listen to the podcast. Produced as a courtesy of Interarbor Solutions: analysis, consulting and rich new-media content production.
Five years is definitely ambitious. ... [But] the sooner the SOA architect’s role is rolled into enterprise architecture in terms of governance the better. It is, as Dave said, best practice in architecture. We’ve known that for a couple of decades actually.
[SOA] fundamentally changes the way we create applications. That means developers need to change the way they are architecting applications, and that’s very different. It's going to take quite a while until we build up the different levels of services.
If you had a "boundaryless information flow," if you had agility, and you could have IT work at the pace of business, what do you think the impact would be on how IT departments actually behave?
It would be a dramatic shift from what we see today. Adopting SOA is a fundamental change in the way that IT operates. It’s a culture change.
We're used to building a solution, putting it into production, and going on to the next project. It’s a very project-based culture [now]. ... If you move to SOA, you have to shift more toward a product-based culture, where you have a life cycle that goes on over multiple versions and doesn’t end until you take that service out of production.
The move from a project-based culture to a product-based culture will be the biggest shift. If you want a good example, look at companies that practice product management, and at the things that they sell, and you will probably get a good idea on how IT needs to operate.
I look at the information integration problem, or master data management, enterprise, logical data model, whatever you want to call it. It's actually a good space to look at and say, “Okay, what do we need to fix to do SOA right?”
We need to figure out how to make this information relevant to the projects that need to execute properly, and take those incremental steps to get us there. Clearly, having a consistent semantic model is critical to the success of SOA. If we don’t get the consistency across our services, we wind up creating more work for the consumers ... It’s not about producing. It's about creating services that are easy for our consumers to use.
Part of a SOA success trajectory would be the ability to consume, as an enterprise, services in a marketplace ... and drive for lower costs and higher benefits. ... My sense is that what has to come of all this is not just a random coupling. There are going to be partnerships. We were starting to talk the other day about semantic integration, but behind every successful semantic integration is a successful human partnership.
SOA not only opens the floodgates to some of these other technologies [such as BI, BPM, analytics and event-driven processes], but also opens the floodgates to more ways of acquiring and consuming services outside the organization.
As you see SOA methodology spreading through the organization and the ISVs, you'll begin to see a more component-oriented way of developing applications that will permeate the commercial software vendors.
We already see popularity of things like mashups, RSS feeds, and content brought to bear on business processes. Do you think that, as SOA matures and we look to the future, there needs to be a delineation between internal and external content, and who's going to be in role of managing that boundary?
... If you have a couple of internal data sources, and maybe Google Maps on the outside and you throw some Salesforce.com data on there too, you can begin to illustrate for upper management what agility looks like. That’s one good thing about mashups.
There is a lot of rogue application development going on there under the radar, that nobody in upper management really knows about. ... Eventually this kind of stuff outside the firewall will be folded into the greater SOA somewhere down the line. In a way, that’s really what's most exciting about SOA, and most different is the ability to begin to connect to those external services and bring them into the fold.
If SOA is successful, it seems like we're dealing with a complexity of integration, but then that opens up the complexity of semantic issues, and people and behavioral issues, and then boundary and political and government issues. So does the business recognize enough return on investment to say that SOA was worth it, and when will we reach that sort of an economic business rationale?
We need to work this from the ground up instead of the grand enterprise data model. We have to take an incremental approach, and don’t try on that project to boil the ocean. Then, after you’ve done that, if you can somehow sell it to the business, there might be some internal budgeting mechanism or brownie points, where there can be some sort of internal trading system, and maybe there is a way to subsidize that extra 20 percent of development.
That’s not going to work, saying "everything is ground up." You need this middle-out approach, but it has to be driven by the business strategy. ... It all has to come back to the business strategy.
The way to determine "Have I been successful?" is, "Have I been successful in adopting my business strategy and meeting my business goals?" If I have, then I am doing the right things. Every enterprise is going to vary the extent to which IT contributes to those goals. ... It all comes back to what the business is trying to do, and to try to understand how IT can contribute to that solution. If I don’t have any idea on how IT contributes, I am never going to be able to say I was successful or not.
Companies are competing in ways that they never had to before. So perhaps competition -- the ability to compete and win markets, to outflank your direct competitors, to partner efficiently, and do mergers and acquisitions well -- is the big payoff from SOA ... because your IT department can keep up with the business strategies.
Circumstances have a nice little way of concentrating the mind. When you, all of a sudden, are faced with putting two organizations together, which happens pretty often in the business -- M&A is not exactly the exception these days -- at some point you have to say, "Look, we need to take an architectural approach. Our tried and true methods have been tried and they are true, but they may not be valuable. We keep just going back on our traditional way, our traditional path of execution, and we're just going to develop ourselves into a brick wall."
No comments:
Post a Comment