SOA in Action

Ronan Bradley provided some of his insights on a recent post I made over at ZDNet on whether EDA is the New SOA.

My original post in turn was inspired by a Rich Seeley interview with John Bates, who could be considered the father of event-driven computing. Bates said that event-driven processing could "create a new physics of computing." He said that in the present paradigm, "data is static, and queries are dynamic." In event-driven SOA, however, data is constantly on the move. "The rules that you're using to monitor the data and take action are fairly static, and it's the data that's dynamic. The data is continuously changing. So you have to structure your software to take into account that paradigm shift."

I also quoted a very well-stated analysis of the event-driven architecture phenomenon by ebizQ colleague Brenda Michelsen. Brenda observed that EDA is not the next evolution for SOA, but an architecture that can effectively work in conjunction with SOA as part of a "business driven architecture."

My sense is that buzzwords and acronyms have limited shelf lives, and after a few years, something new begins to move up the hype cycle. That's why it's likely that at some point in the very near future, vendors may begin to tire of calling everything 'SOA' and move on to the Next Big Thing. EDA is a prime candidate for the next wave.

Ronan, however, says that, no, EDA will not be the new 'SOA,” mainly because the "the level of enforced decoupling in EDA can make it awkward to shoehorn the range of problems that an enterprise architecture has to solve into a pure EDA form;" and "for those problem types that EDA is well-suited for, SOA can be extended with a bit of EDA and therefore do the job."

Rather, Ronan continues, "I see EDA being used ‘on top’ of SOA – to allow identification and processing of unusual events or combinations of events that should generate alerts or recovery processes. SAP for one is already providing some of this type of capability within its NetWeaver product set where BPEL-defined processes can be fired off in response to specified events. This type of functionality will be crucial in terms of delivering control across the SOA-based network of integrated components exchanging more information and information of greater business value."

Mark Palmer, an associate of Bates at Apama, notes that the "distinction between EDA and SOA is still fuzzy." SOA, he writes in a new post, "is designed to support an event-driven interaction between services, but says nothing about how to process those events - that's what CEP does. As a case in point, algorithmic trading systems are event driven. Many of algorithmic trading applications don't use SOA; some do. Therefore CEP is agnostic to the presence of SOA, although, if it's in place, great. Does that mean EDA will "replace" SOA? Certainly not. Does it mean EDA and SOA are complementary? Yes. Does it mean that EDA is an "advanced" form of SOA? I don't think so."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Remember back in the dot-com days when everyone was predicting how "clicks would replace bricks"? Everyone rushed into e-commerce, and a lot of money was spent in the wrong places to achieve uncertain and elusive business goals.

Sandy Carter, VP of SOA & WebSphere Strategy for IBM, worries that too many businesses will attempt, or are attempting, to plunge headlong into SOA the same way, and has some words of advice. In her latest book, The New Language of Business: SOA & Web 2.0, published by IBM Press, Carter builds the case for the book on a study of 456 CEOs that IBM conducted about a year ago. Not surprisingly, CEOs value growth above all else, but flexibility and adaptability in skills also are top of mind in the C-level suite. And there is a direct connection between all three -- companies that had the highest levels of integration and automation of key processes within highly flexible infrastructures showed the most growth as well.

"On the average," Carter observed, "these companies grew earnings 17 points faster than their peers and experienced 1.3 points of improved net profit margin, 1.3 points better difference in ROI, and 0.7 points better difference in return on assets." In a large corporation, each point means a lot of money -- in the tens of millions of dollars and beyond.

Carter defines these companies that can align their resources and achieve lightning speed and agility to rapidly changing business needs as "flex-pon-sive" organizations. And the DNA of a flex-pon-sive business is SOA. But, she cautions, "your journey begins with a focus on a real business problem, not SOA." An incremental buildout of SOA is the key, she says.

Interestingly, Carter attempts to connect the dots between SOA and Web 2.0 (wikis, mashups, collaboration) in the book, noting that they are cut from the same cloth: Technically, protocols such as REST and AJAX -- seen as Web 2.0 standards -- are also enablers for SOA. "Web 2.0 drives the consumption of services. The key is to tie the flexibility of Web 2.0 to service-oriented prinsiples of loose coupling, encapsulation, and reuse that are the heart and soul of SOA." She adds that "it is imperative for business leaders today to ensure that they understand what Web 2.0 is and the advantages that SOA and Web 2.0 can bring to the table."

Carter identified the five "entry points" through which an organization can begin to leverage SOA, each bringing its own sets of benefits:

People -- deliver role-based interaction and collaboration through services. This delivers "improved productivity by putting the user experience within the context of the business process."

Process -- achieve business process innovation through treating tasks as modular services. This delivers "greater innovation and flexibility through faster deployment and modification of business processes."

Information -- provide trusted information by treating it as a service. This results in "better business operations, more informed decision and reduced risk with information delivered in-line and in-context."

Reuse -- service-enable existing assets and fill portfolio gaps with new reusable services. This lowers risk and ensures faster time to market "by leveraging proven, time-tested functionality.

Connectivity -- connect systems, users, and business channels via open standards. This results in "reduced maintenance costs and greater reliability and consistency."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

SOA is stirring seismic shifts in the integration market. Is the need for a lifecycle approach to building, deploying and managing services pushing integration vendors toward developers, and visa versa? Recent announcements by integration stalwarts TIBCO and webMethods -- not to mention BEA and IBM -- would seem to point to an increasing convergence. These points were explored by participants in Dana Gardner's latest SOA BriefingsDirect podcast. I had the opportunity to join Dana, along with analysts Steve Garone, Neil Ward-Dutton, and Jim Kobielus (summarized and linked here).

As Niel Ward-Dutton observes, TIBCO's latest announcement of AcitiveMatrix is much more of a development infrastructure focus than an integration infrastructure focus. "I was really kind of taken by surprise. It took me a while to really get my head around it, because what TIBCO is doing with ActiveMatrix is shifting beyond its traditional integration focus and providing a rear container for the development and deployment of services, which is subtly different and not what TIBCO has historically done."

Steve Garone, however, says that TIBCO's reaching out to developers may be more of an evolutionary than revolutionary step. "This is a logical extension of what companies like TIBCO have done in the past in terms of integration and messaging," he pointed out. "However, it does have advantages for developers who need to develop applications that use those capabilities by abstracting out some of the work that they need to do for that integration. This raises that level of abstraction to eliminate a lot of the work developers have to do in terms of coding to a specific ESB or to a specific integration standard, and lets them focus on developing the code they need to make their applications work."

Dana pointed out that webMethods, with the release of Fabric 7.0, also now provides development capabilities. Jim Kobielus agreed, noting that Fabric 7.0 is similar to TIBCO's ActiveMatrix in that "it's a strong development story and a strong virtualization story. In the case of webMethods Fabric 7.0, you can develop complex-end-to-end integration process logic in a high-level abstraction. It’s a very virtualized ESB/SOA development environment with a strong BPMN angle to it and a very strong metadata infrastructure. WebMethods recently acquired Infravio, and so webMethods is very deep now both on the UDDI registry side and providing the plumbing for a federated metadata infrastructure that’s necessary for truly platform agnostic ESB and SOA applications."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

SOA isn't just for big business anymore. An electrical cooperative and auto parts retailer show how costs can be avoided and customers better served, thanks to SOA.

The Southside Electric Cooperative in Virginia turned to SOA to better manage its growing account base and provide more responsive service. As explained in this recent article, the utility's number of accounts had increased by 73% over the past five years, from 30,000 to 52,000. The utility's goal was to respond quickly to customer requests and service outages. However, the utility had six unconnected databases to store information on outages, dispatches, electricity usage, geographic mapping, billing and accounts receivable.Employees had to manually key in service requests and query several databases just for a single service trip.

Enter SOA. In 2005, the utility began work on its SOA to integrate information from all the separate databases. The goal was to have all databases appear as if they were one, and to create a system that linked all departments and functions to provide employees with reliable information, says Linda Easter Davis, information systems supervisor at Southside Electric.

The systems integrated include a customer information system (CIS), geographic information system (GIS), automated meter reading, financial management, materials management and mobile data. The GIS uses an Oracle database, and the CIS data resides on an IBM i5 operating system.

Southside Electric integrated its six databases using IBM's WebSphere product line, which includes three basic components: messages, adapters and a broker, Davis says. "Messages are the data," she points out. "Adapters are used to retrieve the data from a database and send it to the broker, as well as sending it from the broker back to the database. The broker sits in the middle between all databases and is programmed to know what data needs to be sent to what database."

Southside Electric estimates the efficiencies will help decrease average power outage times from a week to no more than two days.

Davis says one of the biggest challenges was blocking enough time out for the SOA project. "When we first started this, we would hit it for two weeks, then wait, then go another two weeks. Other projects strained the department," Davis recalls. "Finally, we just took a deep breath and said, 'We've got to dedicate a month of time and get this done.' That's the only way I'd ever approach this again."

VIP Auto, based in Maine, employed SOA to modernize its supply chain applications without the need for a painful systems overhaul. VIP installed a layer of software services that provide a common interface to its existing IBM i5-based retail back office systems while also enabling the incremental development and delivery of new in-store, warehouse and back office business processes. (See article here.)

VIP is using Avorcor's SOA for Supply Chain and Logistics (SOA4SCL) solution. The approach has "enabled us to turn the tactical replacement of aging warehouse scanners into a strategic asset for the company, enabling real-time access to inventory data, warehouse operational metrics, and rapid processing of special orders to our retail network," said Dan Grosz, VIP's vice president of information technology. "Going forward we see continued significant benefits from the system in improving warehouse efficiency and supporting electronic commerce."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

There's been plenty of debate as to whether SOA delivers its value via the reuse of services, or through increased flexibility to change business processes. However, one of the big value-adds of SOA may come from its ability to extend the life of legacy systems. An Australian-based health insurer is setting an example of SOA in Action, demonstrating the direct link between SOA and competitive advantage.

The insurance carrier, HBA, is in an intensely competitive market, where price makes the difference. For six years, the insurer has kept its premium increases lower than the industry average through a consistent formula -- keeping operating costs to less than eight cents of every member dollar.

As explained in this recent article, HBA hopes to keep these costs in line over the years to come by repurposing its legacy assets, which represent decades' worth of investment. Plus, the company's programming staff was versed in COBOL, meaning the moving to a newer environment would mean maintaining and staffing for two different language sets. "Once you have multiple languages to work in, we felt restrained with our compact programming team," Peter Powell, CIO of HBA, is quoted as saying.

HBA is porting its COBOL-based applications to MicroFocus COBOL, which will enable pieces of applications to be run on non-mainframe platforms, but still maintain COBOL functionality. "We can now start to look at how to exploit our applications for multi-channel interactions. We can start looking at Microsoft .NET development using the COBOL base to start putting applications on the Web," said Powell.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Too many companies still assume if they deploy an enterprise service bus -- or reasonable variation of an ESB -- that the hard part of SOA is taken care of. This is a misconception that's leading many SOA efforts astray, cautions Anne Thomas Manes, analyst with The Burton Group.

Many SOA efforts will be failing over the next few years, Manes predicted. These failures won't be because of a lack of technology, but because of a lack of organizational wherewithal, she said.

Manes, leading a new ebizQ Webinar entitled "Discover Your Inner SOA," joined AmberPoint's Ed Horst in a discussion of what makes governance so important to SOA efforts. (Link to Webinar here.)

"SOA is really, really challenging, and it’s all about culture, not really about technology. It’s going to deliver enormous benefits in terms of flexibility and agility if you can do it the right way. If you don’t deliver, you're stuck with the status quo, and I don’t of any company that’s really happy with that right now."

If anything, implementing ESBs is the most straightforward part of the architecture -- in fact, most organizations may already have more than one functioning ESB that are called something else, such as integration brokers. The hard part is being able to leverage the value of the service across the enterprise, Manes said. Services need to be designed and tested properly. They need to be kept compliant. They need to be designed for reuse across the enterprise. There needs to be a way to determine what services are actually needed by other groups within the enterprise.

Unlike previous IT initiatives, SOA has a lot of compounding factors, Manes points out. "Number one, it’s unfamiliar territory. Designing services for SOA is different from the way people have been building things in the past. In the past, people built applications to solve a business problem. But they weren't really thinking about what capability is going to be used by another line of business. How do you design a service so that it can actually be reused?"

How does an organization go about assuring that the right services reach the right consumers across the enterprise? Governance is the key. "Without that governance, your SOA is going to spiral into chaos," she said. "Those systems that you’re building are going to end up as brittle as inflexible as ever before. That would be a shame, because you’re spending a lot of money of this stuff, and you’re going to wind up with the same old, same old."

Culture and politics tend to derail many SOA projects, Manes said. "In order to be successful with SOA, you have to treat cultural and political issues associated with SOA. To make that happen you have to put together a decent governance program that addresses the entire service life cycle." In addition, she adds, "governance should be as helpful and as automatic as possible. If it is a hurdle, if people have to do stuff they’ve never had to do before, it typically produces a bunch of resentment -- and people will figure out ways to avoid it."

The more you can automate your governance processes, the better, Manes said. This includes automating the processes and enforcement mechanisms within both development and runtime phases of the service life cycle.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

John Whitridge, vice president of enterprise architecture for Marriott International, sums up the company's SOA philosophy this way: "First, do no harm."

Marriott's approach to SOA is, by design, slow and cautious. Whitridge, who recently gave a talk at the OpenGroup conference in San Diego, was quoted in SearchWebServices as declaring SOA to be a long and winding road. "For us," he said, "SOA is not something we're going to get to overnight." Whitridge said any successful operations will remain in place, and SOA will not be used to upset the apple cart.

Marriott hopes to achieve "increased agility" with services-based applications that can be assembled quickly to respond to changes in the hotel market. The SOA is also intended to provide easier paths to integration with partners, such as Web sites that provide online hotel bookings. The reuse of services would save development costs and get new value out of existing systems, Whitridge believes.

Marriott's SOA approach is heavily focused on the business, not technology, Whitridge also said. Marriott maintains two "watchdog organizations" that bring technology and businesspeople together: an architecture review board, and an SOA services governance board. As a result, the program has more C-level and business manager buy-in.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Here's a good example of policies put in place to drive desirable outcomes: Federal tax credits, along with access to high-occupancy vehicle lanes on the freeways, have helped boost the number of hybrid vehicles registered in the state of California.

That example, put forth by Oracle's Mohamad Afshar and Ben Moreland of The Hartford in a new article published here at eBizQ, draws comparisons between public policy used to encourage certain behaviors, and corporate policies intended to encourage certain behaviors in the development and use of technology.

Many departments, including developers, may be set in their ways, and may need some form of encouragement to sign on to the SOA program.

Afshar and Moreland outline the six steps to successful SOA governance:

1: Define goals and strategy. "A company's SOA strategy must complement and support its goals and business objectives," they said. "This point cannot be overstated."

2: Define policies and procedures. Policies and procedures are as varied as the organization itself. The key is to "clearly state who has decision and input rights in formulating specific policies, how the policies are communicated, how the execution of those policies is monitored, and how adjustments can be made to the policies based on real-life experience."

3: Define metrics for success. This is key for putting the right governance structure in place, Afshar and Moreland say. Such metrics include "the number of projects adhering to processes for project execution, the number of reference architectures leveraged, usability of the reference architectures, the number of exceptions and the reasons for each, the number of sharable services created, the number of applications leveraging the shared services, and the cost saved by reusing an existing service."

4: Put governance mechanisms in place. These include "policies, procedures, enforcement, methods of monitoring, exception handling mechanisms, and so on." Be sure to get executive support to put some muscle behind the program, Afshar and Moreland state.

5: Analyze and improve processes. Be sure to "measure the progress that you have made on your SOA Roadmap, relaxing overly restrictive policies where it makes sense and taking corrective action where necessary."

6: Keep refining your SOA. Re-evaluate, re-evaluate, re-evaluate. SOA is a continuous process.

Just as some new cars can draw upon both gasoline-powered combustion and stored electric power, an SOA is a "hybrid" that draws on multiple resources across the enterprise. Perhaps service-oriented architectures can also help achieve more efficiencies.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

I just heard Zach Friedland, vice president of Merrill Lynch's Enterprise Data Solutions unit, describe how an underlying SOA infrastructure is supporting his company's search and discovery portal. Friedland described Merrill Lynch's vision in this area at FASTforward's Enterprise 2.0 conference in San Diego.

Needless to say, Merrill Lynch is a huge enterprise with many, many silos of data covering a range of processes, from trading to settlement to international equities. A typical user may have had to go to 12 different systems to find the data they needed to manage accounts, Friedland said. "Google raised the bar on search," he said, noting that searching data at Merrill Lynch required filling out complex forms.

The solution Friedland's team arrived at was a single integrated portal, capable of searching 34 million records from nine separate systems. The search capability is leveraged as an XML service that can integrate with applications providing the data. "We wanted to abstract our systems," he explained. "Any client system can seamlessly interact with our transaction systems." Since the system employs XML-based data, "we can literally add a new data source without writing a single line of code," he added.

While Friedland admits that ROI has been difficult to measure, his team has seen plenty of "signs and symptoms that we're doing the right thing." The user base for the portal has been growing, and typical query response times "dropped from 10 to 20 seconds to subseconds."

The main challenge to Friedland's efforts is security, he said. Many of the systems linked into the search portal have their own flavors of security.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

"Nobody was ever fired for implementing an SOA."

Unfortunately, such a phrase does not hold true -- at least not yet. You may remember the phrase "Nobody ever was fired for choosing IBM," which held sway in the 1980s. While SOA has a huge potential upside in lowered development costs and more agility, there is plenty of risk in moving an SOA agenda forward.

In a new article in Java Development Journal, Dave Linthicum has identified this as the SOA proponents' conundrum. "While adding applications, directories, and databases to an existing architecture is easy and risk-adverse, changing architectures around systemic notions such as SOA is hard and comes with risk," he said. "Thus, many are choosing to ignore it. In many instances it's the culture, with some organizations promoting a 'you fail and you're fired' approach versus a 'let's try new things and seek improvement.'"

Before you embark on an organization-transforming endeavor to move SOA forward, Dave poses six questions, which should be answered in the affirmative:

1. Has someone compared the current architecture with best practices in your industry to spot issues that need correction, such as the architecture's inability to align and keep up with the business?

2. Has someone done an ROI analysis of the value of SOA, or other approaches for that matter, for the current architecture and reported it to management?

3. Do you have a complete service-, semantic-, and process-level understanding of your enterprise?

4. Do you have a common abstract model for key elements, such as customers, sales, inventory, transactions, etc.?

5. Are systems well integrated and do they communicate in real-time when needed?

6. Can you change your architecture to accommodate business changes at the speed required by management and the marketplace?

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

I just saw this eBizQ report that Duke University has won IBM's third annual "SOA Case Study Competition." The 24-hour competition challenged MBA students from Duke University Fuqua School of Business and the University of North Carolina Kenan-Flagler Business School to develop a unique business and marketing strategy that is based on a case study.

It's great to hear that students are getting their arms around service-oriented architecture.

IBM reported that the winning team from Duke University "used an emotional appeal for business executives with a theme that SOA helps you with ‘the problems you don’t even know you have." IBM even expects to extend job offers to students by mid February.

But what's really interesting is that the competition brought together 60 MBA students, divided into 15 teams of four, with the challenge of creating a strategy and marketing plan that would articulate the business value of SOA to executives and line of business managers. In other words, (future) business professionals selling SOA to the executive suite. Nothing about the technology. In a successful SOA deployment, the business requirements and processes should be mapped out before technology is introduced.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

Increasingly, integration action is taking place on the browser level. This may require an adjustment in SOA priorities.

My colleague over at the ZDNet blogging community, Dion Hinchliffe, has just posted advice on his own site which suggests that SOA success lies in something called "Reed's Law" (and links to the definition here). Reed's Law states that "the intrinsic value of a network is much, much higher if the network is used in a social manner." Thus, Dion observes, "in some important way, social networks tend to more fully leverage the value of networked applications and services."

With this is mind, Dion provides some pointers to increasing the chances of success for SOA. Here are a few, several more can be found at his site:

Make services consumable in the browser. The browser is where a lot of the integration action takes place, and if a service can't be easily consumed in the browser, the consumer is forced to "build and maintain adapters or using a JavaScript SOAP stack -- if you can find one -- before the service can be used," Dion points out.

Use Ajax as the face of your SOA: As Dion stated above, it pays to keep service consumption within the browser. "The browser model, with our newest high-speed corporate networks, fast desktops, and latest browsers, has finally becoming a very capable way of distributing software and associated updates."

Monetize your SOA: SOA rarely delivers short-term gains, and often can be a money loser in its first few years. That's why Dion recommends that SOA deployers "figure out ways to meter usage, institute chargebacks, and even charge outright fees to external trading partners and customers allows the necessary negative feedback to discourage irresponsible or profligate use of services."

Leverage the "Global SOA" (Web 2.0, that is): Dion observes that he's increasingly coming across "impressive applications that marry the datasets contained within enterprises with the incredibly rich landscape of information out on the Web. And they are primarily impressive because of the data brought in from the Web." Dion correctly observes that "it simply no longer makes sense to have an SOA that does not have access to the Global SOA on the Web where hundreds of high-value APIs are available and millions of lesser ones in the form of RSS and ATOM."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

At Farm Credit Services of America (FCSAmerica), customer information didn't come easy. It was stored and managed in silos such as a mainframe-based loan accounting system, a third-party CRM system, a custom loan origination system written in Visual Basic, and a Web-based system dealer origination system written in Java.

Information was shared among the systems through nightly batch processing. However, as new report in SearchWebservices explains, FCSAmerica was running out of nighttime to complete an increasing batch load. "Every time we added or built something new, it added to the nightly batch processing," Beth Schmidt, director of application development, was quoted as saying.

Sometimes, the batch processing jobs took so long that they're weren't ready for the next business day. Plus, transactions were not in the system until the next day, and employees often were forced to rekey information that was needed for new transactions into another system.

The solution? You guessed it -- SOA.

But FCSAmerica even gave its SOA a name -- "Pinwheel." The SOA -- a shared-services CRM system, replaced this tangle of point-to-point connections with a single integration point. Information is processed through Pinwheel, stored in a "customer truth center" and published back to the customer-related systems, SearchWebservices reports.

Schmidt said the company was in process of having its VB-based loan origination system rewritten in VB.NET, and decided to extend the effort to reworking the system to share customer information across its business units. The implementation was built around Microsoft's BizTalk 2004.

The entire project took about 18 months, complete with the organizational issues you would expect with such a major transformation. "Everyone had different business rules," Schmidt said. "The process of getting them to agree on one standard was lengthy and difficult, and testing was lengthy because of the amount of things changing."

FCSAmerica's experience represents the classic, down-to-earth business case for moving to SOA. Many companies are saddled with plethoras of legacy systems that require end-users to log in and rekey information multiple times. Through composite applications and a service layer, organizations can see immediate savings from increased productivity, less data entry time, and faster responses to customer inquiries.

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)

I was listening to an interview Gian Trotta just conducted with The Open Group's Allen Brown, when something dawned on me. Open Group had just announced a new association formed to promote the professionalism of SOA leaders, but doesn't even mention SOA. Brown doesn't use the term SOA, and the press release doesn't mention SOA. Yet, it's obviously about SOA, and the reason Open Group launched the association is because of a dearth of SOA-savvy professionals to meet the rising demand in the market.

An oversight? Definitely not. Rather, it may be a understanding that the term SOA (but not the principles) may have a limited shelf life. The Association of Open Group Enterprise Architects (AOGEA), a professional association for enterprise architects, has been founded with the hope of lasting the ages.

In a previous career, I was director of a management association, AMS, that was originally established in 1919, and currently work closely with the SHARE independent IBM user group, which has been around since 1955. A group that is able to meet very fundamental career requirements and is responsive to changing member requirements can look forward to decades of growth. I have seen other professional groups that were latched too tightly to technology waves rise and sink quickly as the wave subsided.

It appears that Brown and the Open Group decision-makers very astutely kept the term SOA out of the founding documents simply because no one knows what people may be calling it five or ten years down the road. I would not be surprised if vendors begin backing away from the term 'SOA' at some point in the near future and begin to glom onto something newer and trendier. What we call SOA today may be "Event Driven Architecture" or "Software as a Service" or even "Enterprise 3.0" by 2010.

The group's goal is to set and promote professional standards, "much like the fields of law and accounting." The effort builds on the group's TOGAF certification for both professionals and products, which does address SOA as an underlying architecture.

More significantly, the founding of the professional association also signifies a recognition by the industry that people need to be designated to lead the charge to the principles of SOA. The goal, Open Group says, is to "effectively align IT with business goals, organizations must increasingly adopt a city planner perspective of the enterprise. This has created strong demand for a new class of highly skilled professionals called enterprise architects who can communicate effectively with every level of their organization."

My colleague Gian Trotta just posted a podcast with Allen Brown, president and CEO of The Open Group (posted here), in which he describes the need for a professional class of enlightened architects to lead the charge.

It's about breaking down the silos, Brown said. "Many organizations have managed to break down the silos and barriers within and between their enterprises, getting people working cross-functionally," he observed. "But the issue they face in a lot of ways is that the data that they require, and the information they require is buried in silos and applications that were constructed for very good reasons, and will remain for a long time within the silos. Now we need to rise up above that, and not just take a single application view, but take a city planner view across the enterprise. And to do that, we need someone who can take that city planner, that big picture view."

The enterprise architect is just the person who can take this 30,000-foot view, Brown continued. "The enterprise architect has got to have expertise that spans business, IT, and data architecture. They've got to have a broad understanding of each. They don't need to be deep technical experts, but they need to have a sufficient understanding. of technology. They also have to have an appreciation of the business side -- a 'city planning' view of the enterprise."

Posted by joemckendrick in SOA  |  Permalink  | Comments (0)  | TrackBacks (0)