Do we need more that SOA for a modern application architecture?

Do we need more that SOA for a modern application architecture? By Eric Roch (Chief Technologist)

I am presenting a webniar tomorrow on crating applications using modern architecture - registration.

There is more involved in building a modern architecture than just Service-Oriented Architecture (SOA). While SOA is certainly a big part of the solution, a total modern architecture also includes leveraging business process management (BPM), data management and Web 2.0 technologies.

SOA alone does not implicitly improve governance, IT strategy or business alignment, and top-down, strategic SOA has been largely disappointing. Join us as this month’s Perficient Perspectives looks at how you can leverage your existing IT investments to create a truly modern architecture.

Discussion topics include:

• The promise, hype and reality of SOA
• SOA and data management
• SOA and BPM
• SOA and Web 2.0
• Putting it all together
• Case Study: Architecture modernization
• Case Study: SOA, BPM, and data service
• Maximizing SOA benefits and ROI

Speaker Eric Roch is Principal, SOA/Integration Solutions and GM of Perficient's national TIBCO EAI practice. He has more than 20 years' experience in IT and has been working extensively with SOA technologies for 10 years. Eric has designed and managed SOA projects in excess of 500 services and with budgets over $10M. He is a regular speaker at IT industry events maintains the popular Business Integration and SOA blog.

As Chief Technologist and National Practice Director for SOA with Perficient, Inc., I get the opportunity to work with a lot of customers implementing SOA. See my bio page for my contact information or just post a comment if you want to talk about your SOA projects.

Source: For more SOA Service Oriented Architecture information, visit Toolbox.com.

SOA 2009: Do we need architects or firefighters?

ZDNet blogging colleague Ian Finley just posted an interesting question that reflects ever-shifting priorities in today’s rough-and-tumble economy: “When the building’s on fire, who calls an architect? …No one does. They call the fire department.” He advises enterprise architects and vendors alike to put down their plans and ESBs, put on firefighters’ hats and boots, and get in there and help battle the flames.

It makes perfect sense that priorities need to be focused on marshaling resources on the “right projects.” Ian says the current economic situation is actually a great opportunity for enterprise architects and vendors to show the mettle of SOA, and I agree. This is the time to demonstrate how SOA can deliver greater efficiencies, agility and faster time to market than the old way of doing IT. And, indeed, we see SOA returning to its more entrepreneurial roots, with more projects addressing pressing tactical issues, led by smaller, more agile teams.

Interestingly — and I never considered this — Ian compares the current time to the Y2K crisis of a decade ago. As he puts it, “You have to go back to the Y2K panic to find a time when so many companies had the same #1 requirement.”

However, just to put things in perspective, there’s nothing new about the crisis “firefighting” mentality regarding IT deployments. In fact, that’s been the problem all along. This mentality has stretched IT resources thin for years now — through good times and bad. In fact, firefighting may even be more intense in fast-growth times, because companies are scrambling to add new lines of business and increase market share, creating plenty of digital waste and stretching IT resources way beyond their limits.

Yes, enterprises need to be faster moving and more entrepreneurial. But IT planning looks two to three years down the road, as it must. When you drive, you’re not looking down at the space in front of your bumpers — you’re looking 100, 200, 300 yards ahead to the horizon, to anticipate what’s going to happen.

Remember, economic slumps don’t last forever. It’s likely the recovery will kick in sooner than we think. And when it does, it will be fast and furious with pent-up demand, especially as business technology wishlists come back online. And the firefighting will continue.

A deliberate, more long-term architectural approach is needed as well — throwing hardware, software, resources, and consultants at problems willy-nilly in firefighting mode is expensive and gums up agility, and that’s what keeps happening. And that’s what SOA is supposed to tamp down.

By Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.

Source: SOA Service Oriented Architecture information at ZDNet.

Five fearless predictions for SOA 2009

The year 2008 was the best of times and the worst of times for service oriented architecture.

SOA seemed to become more and more pervasive across companies, and many companies in general seemed positive about the results being delivered so far. At the same time, there has been no shortage of anti-SOA backlash and skepticism about the return on investment and business value of SOA.

What lies in the year ahead? Here are some fearless predictions about the shape of things to come:

1) Economic turmoil will return SOA to its roots — bottom up, incremental. Uncertainty in the economy will carry through 2009, but we’ll move into the recovery stage. However, this won’t change the razor-edge competitive environment — companies will continue to seek solutions that help streamline and cut costs. This is a natural role for SOA-based practices — remember, Web services and SOA were forged in the wake of the downturn of 2001 as a way to increase IT efficiency and value to the business with minimal additional investments. There will be fewer big-bang SOA projects rolled across the whole enterprise, and many more incremental, bottom-up efforts — many of which may be under the radar. More guerrilla SOA, if you will. SOA will also make it easier for companies in mergers, acquisitions, or restructurings to reconstitute themselves.

2) Vendors will de-emphasize SOA as a distinct “product” offering. There will be less hype about SOA, but that doesn’t mean it will have gone away. New solutions and applications will have service-oriented aspects. Cloud offerings will be built in accordance with SOA principles. There won’t be a lot of start-up vendors pitching SOA solutions, but plenty of start-ups will be offering Web 2.0-type and cloud-based services, which will be underpinned by SOA principles.

3) Internal clouds and micro-outsourcing. There has been a lot of industry discussion about the “internal cloud,” in which services are provided to users and systems within organizations. The beauty of internal clouds, of course, is that they offer more control over applications and data. Clearly a natural role for SOA, which will be the backbone of any emerging internal clouds. As part of this role, expect to see SOA play a greater role in grid computing and virtualization as well. Externally as well, more SOA initiatives will include services from outside the firewall — a sort of “micro-outsourcing” of application functionality.

4) More attention to the data element. Companies may do a great job of streamlining and leveraging processes, but often ignore the quality and viability of the data flowing through these processes. Which makes for unsuccessful processes and unsuccessful SOA. At a time when “competing on analytics” will make a difference, companies will be paying more attention to the data their SOAs are serving up.

5) More Web 2.0 tools in the SOA world — and new governance issues. The convergence of Web 2.0 and SOA practices means more interesting approaches to old problems, such as gathering business intelligence. And mashups — many of which may even be designed by users themselves under the watchful eyes of IT — will become the default composite application of choice for accessing services both internally from SOA-enabled systems and externally. Organizations that have already been wrestling with governance issues for SOA will find themselves with the question of how deeply to regulate mashups and other Web 2.0-ish activities.

By Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.

Source: SOA Service Oriented Architecture articles at ZDNet.

SOA in and beyond the credit crunch

Service-oriented architecture in and beyond the credit crunch by Jim Mortleman

There has been much debate recently over the fate of "service-oriented architecture" (SOA).

In January, Burton Group analyst Anne Thomas Manes declared the term effectively dead, a victim of the hype muddying its meaning and the budget cuts affecting large IT projects.

The discussion continued at the SD West conference in Silicon Valley earlier this month, where a series of panellists tore strips off SOA.

David Platt, author of " Why software sucks and what you can do about it" said, "Like any other buzzword it got thrown at everything to see where it would stick."

But, although a majority feel the term has been devalued, even its harshest detractors believe the fundamental concept it embodies - a set of loosely coupled, interoperable business services which talk to one another using open web protocols - is very much alive.

Such an approach allows organisations to build and deploy new applications and services quickly, using whatever mix of in-house and external services best serves their needs.

As Thomas Manes wrote, "SOA is survived by its offspring: mashups, business process management (BPM), software as a service (SaaS), cloud computing and all other architectural approaches that depend on services."

Dennis Quan, director of autonomic computing development at IBM, drives much of the company's cloud computing agenda. He thinks SOA will be critical to the emerging cloud IT landscape.

"SOA is still very much in play. Cloud computing is about delivering highly scaleable services across the network and right at the heart of that is the notion of services.

"In the beginning, a lot of the focus was on software as a service, but today we are seeing it applied more broadly, with the emergence of things like processing power, platforms, storage and applications as a service - delivered from large, scaleable (and often multi-tenanted) datacentres. SOA provides the framework both for managing the cloud centre and tying together services into the composite applications customers end up using," he says.

Analysts such as Gartner have been talking up cloud computing since the crunch, lauding its potential for cutting costs. It is true many firms are looking at consolidating server farms by virtualising their infrastructure - but how many have made a strategic commitment to deploying a service-based architecture on that virtualised infrastructure, or plan to use externally-hosted cloud services?

Nick Kirkland, chief executive of IT leaders' forum CIO Connect, says, "It is a very, very small proportion. The service providers who support this stuff have a very gung-ho, can-do attitude. But the message we are getting back from our members - some of the most senior CIOs in the country - is that they are listening, but they are not convinced yet.

"There tends to be a range of thoughts from the high-level 'this could change our cost model' to the low-level 'Google Mail went down last week - how could I run a business on that sort of thing?'.

"Fundamentally, people are still asking what this actually means. Indeed, we are running a briefing on this shortly to try to clear up some of the confusion."

But he stresses interest is rising, and more CIOs are "dipping a toe in the water".

"An increasing number are trying out cloud computing in a careful way for projects that do not involve sensitive data," Kirkland says.

But corporate CIOs need to balance the much-touted cost-efficiency benefits against issues such as information security, project management, availability, governance and data portability. Since cloud standards for all these issues are still evolving, CIOs of large organisations are unlikely to buy wholesale into the concept of cloud-based SOA just yet.

Psychometric testing provider SHL has been using the cloud for a year for development and trialling purposes. Chief information technology officer Andy Ross says, "We are very pleased with the results: it was quick and very cost effective to set up with the provider we used.

"We do have to put more daily-type support in than we would like, and for that reason we see it as a development or quasi-production tool rather than a full-blown production environment - but I can see that coming.

"We are a Microsoft shop and fully virtualised using Capgemini's utility infrastructure so we are already part-way to achieving the full flexibility of the cloud. My advice would be for rapid trialling and development, you should try the cloud. For production, we want to see a bit more maturity."

But IBM's Quan says it is vital to separate the idea of public cloud computing (where an external provider offers hosted, cloud-based services to clients, such as Amazon's EC3 and S3 cloud-based processing and storage services, or Google's Apps suite) from internal or private clouds.

The latter, Quan says, can be employed as the basis of an organisation's SOA without putting data or processes at any more risk than normal. "There has been a lot of attention placed on public cloud centres, but we believe the private cloud - whether managed in-house or by a trusted provider - is central to the hybrid cloud computing strategy we think will become dominant in the next two years.

"With the right architecture in place, cloud-based datacentres offer organisations lower management costs, the ability to bring services online very quickly, and elasticity of resources. At the same time, they are able to gain these economic benefits while still retaining fine-grain control over their data security and governance models," he says.

Guy Bunker, chief scientist at Symantec and a member of cross-sector security task force the Jericho Forum, agrees private clouds mitigate many of the risks for large organisations. But he also believes companies need not eschew public cloud services completely, since these will likely form a major part of corporate IT once standards have settled down.

"Some of the companies using the cloud in earnest - such as big pharmaceutical companies like Eli Lilly and AstraZeneca - are doing exactly that. They are using Amazon's EC2 for certain services, but not for those handling any sensitive data.

"Large organisations should look at public cloud services, but they need to be aware of the pitfalls so they can ask the right questions of their providers.

"Then, depending on their appetite for risk, they can decide whether a particular function, application or whatever is suitable for the cloud given its current state of maturity," Bunker says.

While private clouds offer significant benefits for risk-cautious businesses, Richard Hall, founder of cloud computing consultancy CloudOrigin and an experienced former corporate chief technology officer himself, believes the sheer economies of scale achieved by public cloud providers will inevitably mean they dominate in future.

"Although there may be some benefits looking at internal clouds, particularly as a sandbox to explore concepts, I suspect the real commercial benefits (savings on infrastructure and, unfortunately, headcount) will kick in only when an organisation moves to a major public cloud platform," Hall says.

In 2009, the companies with most to gain from cloud computing will be industrial-scale users of infrastructure looking for major savings, or startups who never want to make heavy IT investments. Such companies should be looking at the architectural choices for cloud platforms with respect to software design and infrastructure deployment.

Many will actively trial technology and approaches this year, with a view to deployment into 2010 as the major platforms such as Windows Azure mature into production," says Hall. "Then I think the first few snowflakes we are seeing now will turn into a full-blown avalanche," he says.

Case study: Isle of Man

On a budget he jokes is "less than John Prescott's expense account", Allan Patterson, director of the Isle of Man's government information systems division, has delivered an internal cloud-based SOA that could be a showcase in microcosm for what much larger organisations will be doing in future.

"It is what I would call 'building a virtual house'," says Patterson.

"The foundations are our twin active virtualised datacentres running on a Windows platform and our IP network across the whole government estate of 250-300 locations - GPs' surgeries, schools, sub Post Offices, etc.

"On top of that is the equivalent of the pipework and wiring - the common services - which mean we can build something once and use it many times."

This has drastically reduced the IT organisation's costs, but also brings wider benefits.

Patterson says, "We have seen a massive take-up of online services such as web payments by the business community and individuals - we now have about 5,500 users for online services, which for the Isle of Man is huge.

"I strongly believe this is how we make government-to-business more effective. We have even got people who no longer maintain tax books because they trust us to do it - so there are efficiencies for end-users as well."

Source : SOA Service Oriented Architecture information at ComputerWeekly.com

What a Business Analyst Needs to Know by William Hill

SOA Service Oriented Architecture Articles : What a Business Analyst Needs to Know by William Hill

So you want to be an Information Technology (IT) Business Analyst? If so, BE PREPARED! To be a top notch Requirements Business Analyst, be ready to study/know most of the following topics:
o The IT Project Life Cycle o Understanding The Business o Know how to Initiate and Plan a Project o IT Project Execution o Defining and Scoping the Project o Defining a Work Breakdown Structure o Business Process Models and Domain Models o Gathering Business Requirements o Requirements Management o Know Requirements Traceability o Document Business Rules o Interviewing o Joint Applications Development Facilitation (JAD sessions) o Analyzing and Documenting Requirements o Fit-Gap Analysis o Entity Relationship Diagrams o Extract Transform Load o Data Conversions o Object Oriented Analysis o Business Intelligence o Non-Functional (Technical) Requirements o Use Case Diagrams & Narratives o Use Case Analysis, Design and Realization o Communicating Requirements o Identifying a Solution o Service Oriented Architecture (SOA) o Verifying that the Solution Meets the Requirements o Analyzing Buy vs. Build or Both o Unified Modeling Language (UML) o Rational Unified Process (RUP) o Agile Methodologies o Extreme Programming Methodology (XP) o Scrum Methodology (Scrum)

Because that is what it is going to take to stay employed, either as a Contractor or employee. Information about the above topics can be found at: http://www.businessanalysis-therealworld.com

In today's businesses, IT Business Analysts are often referred to as Technical Business Analyst, Business Systems Analyst, Systems Analyst, and other titles. No matter the title, the primary role of the Requirements Business Analyst remains the same; to examine and document the business needs and participate in recommending an appropriate solution to meet those business needs. Specifically, the Business Analyst elicits, analyzes, validates and documents business, organizational and/or operational requirements.

Notice that the word "Requirements" was inserted in front of the title of Business Analyst. This specialty type of Business Analysis is necessary because corporate America does not understand the many different types of Analyst duties. Be aware that many job descriptions will carry the title of Business Analyst but will not describe the duties of a Business Analyst that elicits and documents business requirements. Some positions with a Business Analyst title might require analysis for reporting processes only and is very narrowly focused in regards to the overall duties of a true Requirements Business Analyst.

It should be expected that the requirements for these positions would dictate that a Business Analyst have several years of business experience, in several industries, along with several years of technical IT experience to have the ability to develop business requirements and recommend automated solutions. In today's real-world of IT projects that IS NOT the case, which is why a high percentage of IT projects fail. The Analyst simply does not know how to capture and document project requirements properly.

This discipline is a relatively new role in the IT projects world of corporate America. So new in fact, that most IT Project Managers have not been trained in the processes of Business Analysis, therefore lending to the possible project failures. An experienced Business Analyst may not only have to perform the Business Analysis role but also mentor a Project Manager.

Since this is an evolving discipline, industry is and will be for years to come, in the process of defining and shaping standards and best practices for this role. Business Analysis encompasses a set of tasks and techniques required to identify business needs to determine automated solutions to business problems regardless of technical platform. Without several years of business and technical experience how can these tasks be accomplished?

Business Analysis is one of the most important steps in developing a software solution. It is crucial in identifying and documenting the business needs of customers and stakeholders in order to determine appropriate solutions and approaches to solving business problems, yet, HR departments and corporate middle-management continually staff IT projects with very inexperienced Analysts to handle the tasks.

A software solution needs to address the business requirements of a wide range of stakeholders therefore the Business Analyst often works closely with other functional areas and typically acts as a liaison between users and technical personnel to help solve business problems. Working with all the functional areas, a Business Analyst's main responsibility is to gather, organize, and document requirements in a format that is appropriate to the technical developers as well as business users. A Business Analyst provides the process, questions, and techniques to efficiently elicit and document the information needed from the business users for successful development of IT projects.

In conclusion, be prepared!

This article is about what it takes to become a true Business Analyst. Something that will definitely help is to do a ton of research on the internet about specific topics of Business Analysis. There are very few web sites that cover the entire IT project life cycle processes. To acquire all the knowledge needed would literally take several years of training programs and cost several thousands of dollars. Try to find a reference web site like http://www.businessanalysis-therealworld.com that specializes in Requirements Business Analysis.

About the Author
This author has been in the IT trenches for 41 years. This experience includes roles as a Technical Business Analyst (IT Contractor) for 11 years, 10 years of Project Lead and Management experience, and 20 years software development experience. Additionally, the author is the proud inventor and author of two different programming languages of which he holds copyright privilages, and, the author of the web site and the ebooks at http://www.businessanalysis-therealworld.com.

Source: SOA Service Oriented Architecture articles at goarticles.com

Component Object Model Explained Easily

SOA Service Oriented Architecture Articles : Component Object Model Explained Easily by Manish Shrivastava

In the process of developing computer applications, developers in software development companies have strived hard to achieve greater efficiency and interoperability. In their attempt to achieve greater efficiency, they have created object-oriented programming, procedure calls and libraries of reusable software. However, there are other ways of creating applications in a more cost-effective manner. Some developers take the advantage of previously created software components, existing tools and software and hardware infrastructure to develop and deploy applications. This approach is mainly referred to as "component software". Microsoft Corporation has gained its monopoly by offering its own set of standards and products for component software. Among them is the Component Object Model (COM). It is a software architecture developed to build component-based applications. COM objects are separate components with a unique identity each. The objects expose interfaces that, thus allow other components to gain access to their features. Their versatility makes them easily fit into an object-oriented program design. This is because they are completely language-independent. COM objects are the main building blocks of developing component-based software in the custom software development scenario. The Component Object Model technology is used in the Windows family of operating systems that allows software components to commune. A Software development service uses COM to re-create re-usable software components and link them together to create applications, thus taking advantage of Window services. The line of COM technologies also includes ActiveX controls, DCOM (Distributed COM) and COM+. COM+ is the name of COM-based services that brings together the technology of COM components. It handles complex programming tasks such as resource pooling, event publication and distributed transactions. .Net developers can also take advantage of COM+ infrastructure as it provides valuable services through the system. For those who are confused with the results achieved by COM and .Net framework, it would be important to note that these two achieve similar results in application development, although Microsoft recommends .NET as the best technology for new application development because it manages runtime environment in a robust way.

About the Author
I am the webmaster at www.synapse-consultants.com - a custom software development company offering numerous services, such as content management, offshore software development, online marketing, search engine optimization, search marketing, and website maintenance services

Source: SOA Service Oriented Architecture information at goarticles.com

SOA Plug-and-Play Services

SOA Articles : SOA Plug-and-Play Services by Finacle from Infosys

Shifting economic conditions and rapidly evolving IT strategies along with mergers and acquisitions have left few banks with an appetite to untangle the morass of legacy systems running their businesses. Due to the siloed architecture within banks, where each business unit has their own systems and islands of information, core-banking replacement is a complex integration exercise. Islands of systems have to be either made redundant or integrated with the new solution based on business requirements and processes.

But this, thankfully, is not holding up progress and innovation, thanks, in part, to the increased adoption of Web services and its conceptual cousin, the Service-Oriented-Architecture (SOA). SOA is neither a product nor a solution. It is an integration framework that binds internal and external services to create a solution. With SOA, instead of focusing on different applications that reside on different computers, the emphasis is on business services that represent several different underlying applications. As SOA can seamlessly be put into practice in existing IT environments it ensures that changes in technology and processes during core banking replacements can be phased out and managed effectively.

The plug-and-play benefits of SOA and Web services promises to increase the pace of innovation in financial services. Clearly, by adopting SOA and process driven core banking solutions banks worldwide can achieve tremendous benefits. Following this, this paper describes a banking solution framework which depicts how SOA delivers maximum agility.

Read the complete white paper




About the Author
Finacle solutions address the core banking, e-banking, Islamic banking, treasury, wealth management and CRM requirements of retail, corporate and universal banks worldwide.

Source: SOA Service Oriented Architecture information at goarticles.com

Getting value out of SOA

SOA Articles : Getting value out of SOA by Sandy Cosser

According to Wikipedia, SOA (Service-orientated architecture) can be defined as "a group of services that communicate with each other". SOA is designed to offer simple service solutions to save people and machines a great deal of time. Research firm, Gartner has been studying the adoption of SOA around the world and for 4 years they found that SOA was on the rise. Now, for the first time in 5 years, adoption figures have dropped. Last year's survey revealed that 53% of organisations planned to adopt SOA for the first time, this year that figure was down to 25%.
More bad news for SOA is that companies that have no intention of adopting SOA rose from 7% in 2007 to 16% in 2008. In Paul Krill's article on Infoworld.com, Dan Sholler, Gartner research vice-president, states that there are two major reasons behind SOA's sudden drop in popularity: lack of skills and expertise and no viable business case. Companies also no longer see SOA as essential to their future, but have relegated it to the 'luxury' pile where many IT services find themselves in a recession.

But according to Dave Linthicum, also from Infoworld.com, dropping 'luxuries' such as SOA is an unhealthy reactionary approach and can cost companies more money in the long-run. Linthicum cites Miko Matsumura when he says that companies shouldn't ask whether they can afford SOA now, but rather whether they can afford to miss out on a 5x return in three years.

Linthicum also notes that SOA adoption is widespread in Europe, where he says companies are more forward thinking and future-orientated than companies in the US, who tend to focus on the here and now, as he says the next four months as opposed to the next four years.

Linthicum believes that SOA as a concept has been around a lot longer than many people think, only under a different name. And he contends that the concept of SOA will be here long into the future, although further name changes are likely. He points out that names are unimportant, so long as people continue to buy into the core value of the concept and keep the momentum going, that's what counts.

References:

http://www.infoworld.com/article/08/11/03/SOA_growth_projections_shrinking_1.html http://weblog.infoworld.com/realworldsoa/archives/2008/11/asoa_is_inevita_1.html http://weblog.infoworld.com/realworldsoa/archives/2008/11/soa_is_shrinkin.html

About the Author
Sandra wrote this article for the online marketers DTI Data data salvage and recovery one of the most experienced and expert providers of data recovery services in the UK

Source: SOA Service Oriented Architecture information at goarticles.com

Estimating the Cost of a Service Oriented Architecture (SOA)

SOA Articles : Estimating the Cost of a Service Oriented Architecture (SOA) by David DeWitt

In a recent survey by AMR Research it was found that "Fifty three percent of companies had active SOA projects by the end of 2007." The companies that adopted SOA spent an average of $1.4 million to implement SOA on software and services in 2007. These findings were confirmed in a survey prepared by BEA Systems. The BEA survey reported that half of all enterprises with revenue exceeding $1 billion have shelled out over a million on their SOA efforts and expect to spend even more over the next 12 months.

Financial Services organizations were least likely to be adopt SOA but those that did spent significantly more than their peers in other industries.

So does that mean that most organization will face such a large expense to implement SOA? What is the real cost for a SOA implementation?

In a traditional software estimate one would consider: Software size, Complexity, Technology, and Constraints. These individual factors are counted, weighted, and combined to identify an estimate of total effort. The total hours are then multiplied by cost factors for a total cost estimate.

In the SOA world the underlying fundamentals are much the same. By summing four essential estimation components an estimated cost can be derived. The four components are: Data Complexity, Service Complexity, Process Complexity, and Enabling Technology. (your terms, or a citable source here?)

As with more traditional estimation methods, size matters. In a traditional estimation approach one would identify the size of the problem by estimating lines of code, function points, or by some other method. In the SOA community one is concerned with the number of data elements, the complexity of the data storage for those elements, and the cost to understand and refine each element.

David S. Linthicum of the SOAInstitute.org provides a simple formula for the calculation. Cost of Data Complexity = (((Number of Data Elements) x Complexity of the Data Storage Technology) x Labor Units))

• The "Number of Data Elements" is the number of semantics you're tracking in your domain, new or derived.

• Express the "Complexity of the Data Storage Technology" as a decimal between 0 and 1. (For instance, Relational is a .3, Object-Oriented is a .6, and ISAM is a .8.)

• "Labor Unit" is the amount of money it takes to understand and refine one data element. Dave said this could equal $100, for example.

Example: ((2,000 data elements) X .6 complexity) X $150) equals $180,000 for the total Data Complexity Costs.

Now repeat the same formula for the Service Complexity, Process Complexity, and Enabling Technology. The final total should be within 10 - 20% of the actual costs. However, consideration should always be made for changing requirements, scope creep, changes in technology - and the myriad of additional real life factors that have become lessons learned in traditional software development projects.

The factors that go into a SOA estimate are similar to a traditional estimate in many ways. As was demonstrated above, consideration must be made for size, complexity, staffing, and many other parameters. Products such as SEER for Software™ by Galorath can be used to help identify and quantify the underlying components that make up a SOA estimate. Within SEER for Software the estimate can be built, evaluated, assessed for risk, and delivered as part of a repeatable estimation process.

About the Author
David DeWitt is a Senior Consultant with Galorath based in El Segundo, California. He can be contacted at ddewitt (AT) galorath.com. For more information on the Galorath line of estimating software solutions please visit Galorath.com when estimating software projects or call: U.S. +1 310.414-3222 -- U.K. +44 (0) 1252.724518

Source: SOA Service Oriented Architecture information at goarticles.com

SOA gets an obituary

SOA gets an obituary

Burton Group analyst Anne Thomas Manes has declared SOA dead but says that offshoots like mashups and cloud computing remain alive and well By Paul Krill

SOA is dead but services remain alive, according to a prominent analyst who published an obituary for SOA in a blog post on Monday.

Nucleus Report: Who's ready for SMB? - read this white paper.
In her blog, Anne Thomas Manes, vice president and research director at Burton Group, pronounced SOA dead.

"SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession. SOA is survived by its offspring: mashups, BPM, SaaS cloud computing, and all other architectural approaches that depend on 'services,'" Manes wrote.

Instead of becoming a savior, SOA "instead turned into a great failed experiment -- at least for most organizations," Manes said. SOA failed to deliver on promised benefits and after the investment of millions, IT systems are not better than before. In some cases they are worse, with costs higher and projects taking longer, she said.

Interviewed Monday afternoon, Manes said successful SOA implementations have resulted from major IT transformation efforts rather than just slapping a bunch of interfaces on applications. "Those companies have seen spectacular results from these efforts, but in those circumstances, SOA was part of something much bigger," Manes said.

Are you ready for event-driven business? - watch this webcast.
Companies need to become more in tune with what businesses require and understand what the problems are, she said. What is required is an examination of application architecture rather than project-by-project integration, Manes noted, but with the difficult economy, funding for SOA has dried up, she said.

"All these guys intent on pursuing [an] SOA initiative, they're not going to have any money to do it because the business is not going to continue to fund it," Manes said. In conducting research, she found that the failure of SOA to deliver on initiatives has soured those holding the purse strings.

Still, Manes does emphasize a continuing need for services, such as cloud services. She advised against using the acronym SOA, which has generated a backlash. Instead of people talking about architecture and services, they have focused on such matters as ESBs (enterprise service bus).

"SOA has become a bad word. It must be removed from our vocabulary," she stressed in her blog.

"The demise of SOA is tragic for the IT industry. Organizations desperately need to make architectural improvements to their application portfolios," she wrote. Service-orientation is a prerequisite for rapidly integrating data and business processes and enabling situational development models like mashups. It also is foundational for SaaS and cloud computing, Manes said.

"Although the word 'SOA' is dead, the requirement for service-oriented architecture is stronger than ever," she said. Successful SOA requires disrupting the status quo and redesigning the application portfolio as well as a shift in how IT operates, said Manes.

She cited Bechtel as a company that has had success with services but does not even use the term "SOA."

At IBM, which has been a key vendor in the SOA space, an official on Tuesday morning disagreed with Manes's "SOA is dead, long live services" message.

"I don’t think that is the right message," said Sandy Carter, IBM vice president of SOA and WebSphere strategy. "For me, SOA is alive and kicking moreso than it ever has been in today's economy," she said.

But the marketplace is indeed changing from companies just looking at SOA as a technology to instead focusing on business problems and solving them with SOA, she said.

"We're seeing changes in the marketplace, but I think [these are] changes that are very good," Carter said.

IBM was still seeing its SOA business grow at least as recently as its third quarter, which ended in September 2008, said Carter, noting she could not comment on the fourth quarter because the company is in a "quiet" period. But she acknowledged IT spending overall is being reduced or is flat.

"SOA helps reduce cost and provides business agility, so it really addresses the two biggest concerns going on," she said.

An HP official said companies need to be more in tune with what businesses require and understand application architecture. Funding for technologies that support SOA without a business driver will be very difficult to secure in 2009, said the official, Kelly Emo, SOA product marketing manager for HP Software.

"My response [to the blog] is I think that the issue that really needs to get highlighted in the market is how IT goes about getting funding for their projects in 2009, and I think that's the valuable part of the blog," Emo said.

"What IT has to stop doing is speaking technical jargon to the business. They need to define projects in terms the business cares about," such as emphasizing faster service times and better business processes, she said.

Source: SOA Service Oriented Architecture information at infoworld.com

SOA is architecture with integration

SOA is architecture with integration

Integration by itself has value as a part of architecture, but it's not architecture unto itself.
TAGS: None

The post of the break was one by Joe McKendrick, who says, "SOA is integration. SOA is not integration. Simple as that." In essence, he looks at some of the confusion around the value that SOA brings to the enterprise: Is it integration, agility, or something else? Indeed, there is a renewed debate raging about the relationship between the practices of SOA and integration, according to Joe. He writes:

Agility -- while a commendable goal that everyone needs to shoot for -- is a vague, hard-to-quantify state of existence that SOA-based approaches may or may not be able to accomplish. But the results of integration are often measurable.
At issue is that fact that people want to define SOA more tactically these days. Thus, they want to focus more on the value of the integration byproduct of SOA and not as much on the architectural value of agility. Is this a good thing?

First, let's put things into context. Integration as I defined in my now-aging but popular EAI book, was really presented as an architectural sub-pattern, thus the value of integration within the context of the core strategic direction of the enterprise architecture. In my view, you need both, including defining integration at both the information and service levels (yes, I was talking about SOA in 1996).

First, integration by itself has value as a part of architecture, but it's not architecture unto itself. Indeed, you can have a well-integrated enterprise, but with a crappy architecture that's very difficult to change without breaking a dozen things.

Second, SOA, while also leveraging integration as a sub-pattern -- and integration is a byproduct of SOA -- is really about architecture, or at least it should be. You get to SOA through integration, or more accurately the loose coupling of systems that create and architecture that's easy to change. You can call this agility, changeability, or whatever, but I call it good architecture. Integration indeed has value, don't get me wrong, but the largest value is the ability to get to an SOA, if you ask me. Or, at least to the SOA that's right for your enterprise.

Finally, you can measure the value of agility. I've written on this topic time and time again, and my clients have figured this out time and time again. Some enterprises have huge returns from having an agile architecture, and thus SOA; others not as much, and SOA perhaps should be less of a priority. So, if you can get the value from agility, than leverage integration to get to SOA. Else, leveraging just integration is just fine.

Source: SOA Service Oriented Architecture information at infoworld.com

ว่าด้วย SOA

Service Oriented Architecture SOA คืออะไร

แบ่ง 3 ข้อ
1.ความรู้พื้นฐานเกี่ยวกับ SOA
2.เราจะใช้ tool อะไรในการสร้าง SOA หรือ implements
3.วิธีการสร้าง

1. concept พื้นฐานของ SOA ก็คือมองทุกอย่างเป็น service
อย่างถ้า OOP เราจะมองทุกอย่างเป็น object ใช่มั้ย แต่อันนี้เรามองเป็น service แทน
ตัวอย่างที่เขาชอบยกมาก็คือ service เช่น บริการจองโรงแรม บริการจองตั๋วเครื่องบิน บริการดูราคาหุ้น (Stock Quote)
ซึ่งเวลามองก็จะมองว่า มีบริการอย่างนี้นะ เราใส่ข้อมูลความต้องการเราลงไป แล้วเราได้บริการกลับมา
ซึ่งมันจะต่างจาก object ที่จะมองเป็น properties/behavior

web service ก็เป็น implementation อย่างนึงของ SOA ทำนองเดียวกับที่ Java เป็น implementation ของ OO

web service (WS) ก็จะประกอบด้วยส่วนหลักๆที่ควรรู้จัก 3 อัน ก็คือ WSDL, SOAP, UDDI (ทุกตัวเป็น XML)
ถ้าให้อธิบายคร่าวๆ

- SOAP จะเป็นส่วน transportation protocol คือมันจะติดต่อกันด้วย SOAP
- WSDL จะเป็นตัวอธิบาย มองง่ายๆจะคล้ายๆ interface ก็คือจะอธิบายว่า service นี้รับ parameter อะไรบ้าง ส่งอะไรกลับคืนมา
- UDDI จะเป็นคล้ายๆสมุดหน้าเหลือง เวลาจะหา service ที่ต้องการก็เข้าไปเปิดหาในนี้

Invocation model ของ WS แบบในฝันก็คือ user ต้องการใช้บริการ เช่น อยากจองตั๋วเครื่องบิน ก็ไปดูใน UDDI ซึ่งมันก็จะมีหลายเจ้าที่ให้บริการที่เหมือนกัน ก็เลือกมาเจ้านึง (ซึ่งจะใช้เงื่อนไขอะไรนั้นก็เช่น QoS, Location, etc. )
แล้วก็จะได้ WSDL file (location) ของ service นั้นๆมาจาก UDDI
แล้วพอได้ WSDL file มาแล้วเราก็จะสามารถติดต่อกับ service นั้นๆได้แล้ว

แต่ ปัจจุบัน UDDI มันยังไม่ค่อยมีคนใช้ หลักสำคัญก็คือต้องรู้ WSDLของ service ที่จะเรียกเป็นใช้ได้ ถ้ารู้อยู่แล้วก็ข้าม UDDI ไปได้เลย


2. อันนี้มันมีให้เลือกหลากหลาย ก็แล้วแต่ภาษาแล้วก็เทคโนโลยีที่ใช้ อย่างถ้าจะทำ WS ด้วย Java มันก็มีให้ใช้หลายตัวมากๆเลย อย่างเช่น JWSDP, Axis, และอื่นๆ พวกตระกูล .NET ก็จะมีของมัน

3. ก็ต้องแล้วแต่ technology ที่ใช้
แต่ หลักๆของมันก็คล้ายๆกัน คือถ้าจะสร้าง service ให้คนอื่นใช้ tool มันก็จะสร้าง WSDL file ออกมาให้ แต่ถ้าจะไปใช้ของเขา เราก็ต้องรู้ WSDL ของเขา แล้วเราก็สร้าง class ไฟล์มาเพื่อไปเรียกมันอีกที ปกติถ้าจะทำ web service จากโปรแกรมที่มีอยู่แล้ว ก็แค่สร้าง interface แล้วก็เอามาสร้าง wsdl ด้วย tool แล้วเอาไป deploy ก็ใช้ได้แล้ว

Source: SOA Service Oriented Architecture information at tism50b.multify.com

Java SOA คืออะไร

Java SOA Service Oriented Architecture คืออะไร

SOA (Service Oriented Architecture) เป็นรูปแบบในการออกแบบระบบ (system) หรือ โปรแกรมประยุกต์ (application) แบบหนึ่ง
อย่าง object oriented เวลาออกแบบระบบ เราจะมองเป็น object หรือ class
แยกแยะระบบออกมาเป็น class และความสัมพันธ์ (relations)
แต่ SOA จะมองระบบ ประกอบด้วยการทำงานหรือบริการ (service) ต่างๆ

แล้ว service คืออะไรล่ะ?
service ก็คล้าย function หรือ method นั่นแหละ คือมีหน้าที่ทำอะไรสักอย่าง ถึงเวลาเราก็เรียกใช้
แต่ service มีลักษณะ high level และเป็นมุมมองเชิงธุรกิจมากกว่า เช่น มองระบบธนาคารประกอบด้วยบริการถอน withdrawal service, บริการฝาก deposit service
แทนที่จะมองเป็น class Customer หรือ class Teller ที่มี operation withdrawal หรือ deposit

สิ่งที่ service ทำได้ แต่ method ทั่วไปทำไม่ได้ คือ distributed system
นั่นคือแต่ละ service สามารถถูกเรียกจากต่างระบบ, host หรือ JVM กันได้
แต่ละ service มีอิสระต่อกัน ไม่ได้กระจุกติดกันอยู่ใน application หรือ jar file หนึ่ง
พูดง่าย ๆ service ก็คือ method ที่ถูกดึงมาไว้ข้างนอกนั่นเอง

ข้อดีของ service คือ loose coupling และสามารถใช้ร่วมกันได้ บางคนอาจเถียงว่า method ก็สามารถใช้ร่วมกันได้
แต่ service สามารถใช้ร่วมกันระดับ application ครับ เช่น ธนาคาร A มี Deposit service
ธนาคาร B, C สามารถเขียน application มาเรียกใช้ Deposit service ของธนาคาร A ได้ นั่นคือเป็นการ reuse ระดับ high-level ขึ้นมาอีก

SOA กัน web services

ที่ SOA เป็นพูดถึงกันมากส่วนหนึ่งก็เพราะ web services นั่นเอง ความจริง SOA ไม่ใช่ของใหม่ ถ้าเราสังเกตลักษณะของ service จะมีส่วน implementation แยกกับ interface เสมอ
เพื่อลด coupling ระหว่าง service กับผู้เรียก ซึ่งแนวคิดนี้มีใน J2EE (RMI), CORBA และ COM อยู่แล้ว นั่นคือเราสามารถใช้ RMI technology (ซึ่งเป็น distributed technology) ทำ SOA ได้

แต่ว่า จุดขายที่สำคัญของ web services คือ platform independent ผู้เรียกกับ service ไม่จำเป็นต้องเป็น platform เดียวกัน (java application เรียกใช้ .NET service) ซึ่งต่างจาก RMI ที่ต้องเป็น java หรือ CORBA ที่ต้องเป็น Java หรือ C++

ในปัจจุบันถ้า web services คือหัวใจของ SOA, XML ก็คือเส้นเลือดหล่อเลี้ยงหัวใจ เพราะ XML ทำให้ Web services เป็น platform independent technology ซึ่งช่วยให้สามารถ communicate ระหว่าง B2B หรือ new system กับ legacy system ที่เป็นต่างภาษา หรือ platform ได้

XML เป็น markup language มีลักษณะเป็น text ใครก็เปิดอ่านได้ และอ่านรู้รื่องได้ไม่ยาก ขอให้ผู้เรียกกับ service เข้าใจ xml ก็เป็น web services ได้แล้ว
ซึ่ง technology ที่เกี่ยวกับ web services ส่วนใหญ่เกี่ยวข้องกับ XML ทั้งนั้น เช่น WSDL, SOAP, BPEL

SOA กับ web services จะเป็นเครื่องมือสำคัญในการพัฒนา enterprise application ในอนาคต ด้วยจุดเด่น คือ
1. loose coupling
2. ความคล่องตัว ปรับเปลี่ยนง่าย
3. high reusability
4. ที่สำคัญช่วยลด cost ในการ mainteinence

ตามหลักการแล้ว web service สามารถเรียกข้ามองค์กร (cross organization)ได้ แต่ว่า spec บางอย่างของ Web services ยังไม่นิ่ง เช่น security, trasaction, และ QoS ต่าง ๆ
ดังนั้น การใช้ SOA ส่วนใหญ่จึงเป็นการเรียกใช้ web service ภายในองค์กรของตัวเองเท่านั้น
สิ่งที่ทำได้ตอนนี้ คือ เกาะติดความก้าวหน้าของ SOA และพิจารณาความเสี่ยงเมื่อนำ SOA มาใช้อย่างรอบคอบ เพราะ SOA ก็มีต้นทุนสูง, learning curve พอสมควร
และที่สำคัญจะได้ไม่เป็นเหยื่อคำโฆษณาของเหล่า vendor นั่นเอง

จากบทความก่อนหน้า ผมบอกว่า web service (WS) ก็คล้าย method แต่ว่าถูกดึงออกมาอยู่ข้างนอกลอย ๆ
ที่นี้เราจะทำอย่างไร เพื่อเรียกใช้มันเพื่อสร้าง application หรือ business process ที่ประกอบด้วย web service หลาย อัน

ก่อนอื่นขอแบ่งประเภทของเว็บเซอร์วิสเป็น 2 ประเภท

1. Atomic web service - เว็บเซอร์วิสทำงานด้วยตัวเอง ไม่จำเป็นต้องพึ่งพาเว็บเซอร์วิส
2. Composite web service - เว็บเซอร์วิสที่ต้องเรียกใช้เว็บเซอร์วิสอื่น เพื่อสร้าง service ของตัวเอง

จากนั้นเราแบ่งจุดประสงค์ของการเรียกใช้ WS เป็น 2 แบบ

1. เรียกใช้ เพราะเราต้องใช้จริงๆ ผู้เรียกมักเป็นend user client เช่น ผู้ใช้ส่งข้อมูลไปยัง WS ของบริษัททัวร์ เพื่อซื้อ packageทัวร์
2. เรียกใช้ เพราะจะไปให้คนอื่นใช้ต่อ ก็คือ Composite WS นั่นละ ต้องเรียกใช้หลายๆ WS มาประกอบกันเพื่อสร้าง service ของตัวเอง
เช่น WS ของบริษัททัวร์ เรียกใช้ WS ของโรงแรมเพื่อจองห้อง, สายการบินเพื่อจองตั๋ว และธนาคารเพื่อตัดยอดเงิน

การเรียกใช้ web service มี 2 วิธีหลักๆ ได้แก่

1. ใช้ Web service client API เช่น WSIF, WSE เป็นต้น ก็คือเราเขียน application (ด้วยJava หรือ .NET) ของเราไปตามปกติ
เมื่อถึงเวลาต้องเรียกใช้ WS ก็เรียกใช้ API แทน เหมือนกับการเขียนโปรแกรมปกติทั่วไป วิธีนี้เหมาะกับ end user client ที่เป็นผู้ใช้ปลายทางจริงๆ
เพราะไม่ค่อยมีการเปลี่ยนแปลงบ่อย และมักเรียกเพียงไม่กี่ service
อย่างไรก็ตามวิธีนี้ไม่เหมาะกับการสร้าง Composite WS เพราะเรามักใช้ Composite WS เพื่อสร้าง business process
(business process คือ บริการที่เห็นหรือสัมผัสได้โดยตรงจากผู้ใช้หรือลูกค้า และให้ผลตอบแทนกับองค์กร นั่นก็คือservice นอกสุดที่ให้บริการลูกค้าโดยตรงนั่นเอง)
ซึ่งมี business logic ซึ่งอาจเปลี่ยนแปลงบ่อยๆ นอกจากนี้ business goal ของการสร้างapplication ด้วย WS ก็เพื่อความคล่องตัว (agility) ปรับเปลี่ยนง่าย จะได้สอดคล้องกับสภาพธุรกิจปัจจุบันที่มีการแข่งขันสูง ดังนั้นการผูกแต่ละ WS ไว้ด้วยการ coding แบบเก่านั้น จึงไม่เหมาะกับการสร้าง business process ด้วย WS
ตามหลักการของ SOA

2. ใช้ WS ตัวกลาง (mediator) มาเรียกใช้ sub-WS นั่นคือใช้ BPEL (Business Process Execution Language) นั่นเอง
การจะสร้าง business process หรือ composite WS จาก BPEL ต้องประกอบด้วย 2 ส่วน ได้แก่
2.1 BPEL file - BPEL เป็นภาษาที่ไว้ใช้กำหนด business process ซึ่งจริงๆ แล้ว เป็นภาษา xml
ลักษณะของ BPEL คือ เป็น procedural language คล้ายกับ flow chart ทำหน้าที่กำหนดว่าจะเรียก WS ไหน, เมื่อไหร่ และอาจเก็บตัวแปรด้วย
การทำงานจะไปข้างหน้าเรื่อย ๆ จนจบไฟล์ (ลองนึกถึง file build.xml ของ Ant อาจเข้าใจ การทำงานคล้ายอย่างงั้นเลย)
2.2 BPEL engine คือ ตัวที่จะมาอ่าน BPEL ที่เราเขียน และ สร้าง composite WS ให้ทำงานตามที่กำหนดใน BPEL นั่นเอง (คล้าย Ant tool ที่อ่าน build.xml)
client ที่เรียกใช้จะเห็น composite WS ที่สร้างขึ้นเป็นเหมือน WS ทั่วไป
BPEL engine ปัจจุบันก็เช่นBPEL manager ของ oracle ซึ่ง vendor ส่วนใหญ่จะมี BPEL designer ติดมาด้วย เพื่อสร้างและแปลง flow chart เป็น bpel (อย่างที่บอกว่าbpel เป็นภาษาที่เหมือน flow chart อยู่แล้ว ไม่มีแยก function มี control flow แค่switch-case, loop และก็อย่างอื่นอีกนิดหน่อย สามารถดูตัวอย่างได้ที่ link อ้างอิง)

นอกจากนี้ BPEL ยังสนับสนุนการทำงานแบบ concurrent, asynchronous และ exception handling ด้วย อย่างไรก็ตาม BPEL ก็คือ procedural language
ที่ไว้ใช้สร้าง Composite web service โดยการระบุการเรียกใช้ WS อื่นๆ เพื่อสนับสนุนแนวความคิดของ SOA นั่นเอง

Source: SOA Service Oriented Architecture information at ct.rmutr.ac.th

Service-Oriented Architecture (SOA) คืออะไร

SOA Service-Oriented Architecture คืออะไร

เมื่อการแข่งขันมาถึงจุดที่การให้บริการลูกค้าเป็นสิ่งสำคัญมากกว่าการแข่งขันเรื่องราคา หรือผลิตภัณฑ์ใหม่ๆ ที่ใครๆก็สามารถทำได้ เหตุนี้ทำให้องค์กรต้องปรับเปลี่ยนรูปแบบการให้บริการเพื่อขยายให้ทันกับความต้องการของลูกค้า ตัวอย่างเช่น บริษัทผู้ให้บริการโทรศัพท์เคลื่อนที่ ในการสร้างบริการให้ลูกค้าเข้าถึงด้วยการเข้าใช้บริการผ่านร้านให้บริการ ไม่ว่าจะเป็นการเปิดบริการ ซ่อมเครื่อง รวมไปถึงสอบถามบริการผ่านคอลเซ็นเตอร์ แทนที่จะเข้ามารับบริการที่ส่วนกลาง

ทว่าระบบต่างๆที่กระจายอยู่ตามร้านให้บริการ และคอลเซ็นเตอร์นั้น ต้องพึ่งระบบไอทีจากส่วนกลางในการให้บริการ

ดังนั้น ระบบไอทีหลังบ้านจึงจำเป็นต้องสนับสนุนการทำงานที่ขยายเพิ่มขึ้น !!!

ดังนั้น แนวคิดการใช้ SOA (Service-Oriented Architecture )จึง เกิดขึ้น เพราะการใช้ไอทีในองค์กรไม่ได้จำกัดอยู่เพียงการใช้ซอฟต์แวร์สำเร็จรูป ที่ไม่เพียงพอต่อการทำงานที่เพิ่มขึ้น อีกต่อไป

SOA กระทบโครงสร้างไอทีขององค์กร

SOA ไม่ใช่ซอฟต์แวร์ หรือ แพ็คเกจ นายพัฒน์พงศ์ บุปผรัตน์ ที่ปรึกษาอาสุโสด้านธุรกิจและหัวหน้าทีมพัฒนาธุรกิจขององค์กร บริษัท เครือเจริญโภคภัณฑ์ จำกัด อธิบายถึงแนวคิดของ SOA ว่า SOA แบ่งเป็น 2 คำ Service-Oriented และ Architecture

คำแรก Service-Oriented เป็น Software ที่ไม่ใช่ซอฟต์แวร์ แพ็คเกจ แต่เป็นซอฟต์แวร์ตัวเล็ก ทำงานเฉพาะด้าน ขึ้นอยู่กับว่าจะแบ่งเป็นบริการอะไรบ้าง

คำที่สอง Architecture คือการออกแบบ โดยจะมององค์กรโดยรวมว่าต้องการบริการอะไรบ้าง ก็จะแบ่งบริการนั้นๆออกเป็นส่วนย่อยๆ

ทั้งนี้ หลายคนมองว่า SOA คือ web service แต่จริงๆแล้วไม่ใช่เพราะ web service เป็นแค่เครื่องมือในการใช้งาน

ดังนั้น SOA จึงไม่ใช่สินค้า หาซื้อไม่ได้ แต่มันคือแนวคิดที่ต้องสร้างเองในองค์กร

สำหรับสินค้าที่เกี่ยวข้องกับ SOA ประกอบด้วย 4 ส่วนคือ

Enterprise Service Bus เป็นโครงข่ายสำคัญในการขับเคลื่อน SOA ทั้งหมด เป็นการเชื่อมต่อระหว่างแอพพลิเคชัน
Design-Time Governance เป็น ดาต้า เบส กลางช่วยรวบรวมว่าองค์กรมีบริการอะไรบ้าง และช่วยนำบริการออกไปยังหน่วยงานและควบคุมบริการให้เหมาะสมกับองค์กรด้วย
Run-Time management เป็นตัวจัดการ ทำอย่างไรให้บริการทำงานสอดคล้องกับ SOA ที่ตั้งไว้ และ 4.Security Gateway ในที่นี้ไม่ได้หมายถึง Firewall ที่เป็นเน็ตเวิร์ก แต่เป็น Application Firewall ที่เข้าใจ คำสั่ง XML นอกจากนี้ต้องมี Application Delivery Control ช่วยเร่งความเร็วในการทำงานของ SOA ด้วย
เมื่อนำแนวคิด SOA เข้ามาใช้ แอพพลิเคชันแบบเก่าต้องถูกรื้อใหม่

จากแนวคิดเรื่อง SOA ทำให้เกิดการทำ Software as a service (SaaS) และ web 2.0 ขึ้น

SaaS คือ แอพพลิเคชัน แต่ไม่ใช่ แอพพลิเคชันตัวใหญ่ มีหน้าทีทำงานเฉพาะด้านในด้านหนึ่ง โดยการใช้งานของผู้ใช้ ไม่จำเป็นต้องเป็นเจ้าของแอพพลิเคชัน สามารถขอเช่าใช้งาน โดยมี Vender หรือหน่วยงานที่เกี่ยวข้องเป็นผู้ดูแลรักษา

การ์ทเนอร์ คาดการณ์ในปี 2010 ซอฟต์แวร์ทุกอย่างจะเป็น SaaS ในสัดส่วน 25%

ขณะที่ web 2.0 หลักการคือ คนใช้งานเป็นผู้จัดการข้อมูลได้ด้วยตัวเอง เจ้าของเว็บไซต์เป็นเพียงผู้ให้บริการ ไม่ใช่เจ้าของที่ทำหน้าที่ให้ข้อมูลเพียงฝ่ายเดียว การให้ข้อมูลต้องเกิดจากผู้ใช้งานและเป็นข้อมูลที่มีการสื่อสารได้ 2 ทาง

ตัวอย่างของสิ่งที่เกิดขึ้นจากแนวคิด web 2.0 ที่เห็นในตลาด ได้แก่ Blog ที่เจ้าของและสมาชิกเข้ามาแลกเปลี่ยนข้อมูลกันได้ ทำนองเดียวกับ Wikipedia หรือ Google Adsearch ที่ผู้ใช้สามารถเข้าไปควบคุมการทำงานว่าต้องการได้รับบริการรูปแบบใด

เมื่อเทรนด์เป็นเช่นนี้ องค์กรต่างๆที่ต้องการสร้างบริการให้เกิดความพึงพอใจแก่ลูกค้าจำเป็นต้องนำแนวคิดนี้ไปสร้างให้เกิดประโยชน์ในทางการตลาด

ช่องโหว่ SOA ที่ไม่ควรมองข้าม

ทว่าแนวคิด SOA ก็ต้องได้รับความปลอดภัยสูงเช่นกัน ในมุมมองของผู้ผลิตอุปกรณ์เครือข่าย อย่างบริษัท ทรีคอม (ประเทศไทย) จำกัด โดยนายสุรชัย ไชยรังกิจรัตน์ กล่าวว่า แนวคิด SOA คือการออกแบบอยู่บนซอฟต์แวร์ที่แยกกันเป็นส่วนๆ ถ้ามีซอฟต์แวร์ 10 ตัว ระบบก็ต้องรายงาน 10 ตัว ไม่เหมือนซอฟต์แวร์แบบดั้งเดิมที่รายงานรวมกันทั้งหมดเพียงครั้งเดียว

นอกจากนี้ เนื่องจาก SOA ใช้ web service เป็นเครื่องมือ ที่วิ่งอยู่บน Protocol XML ดังนั้นจึงเป็นมิตรกับมนุษย์ นั่นหมายถึงคนสามารถเข้าไปอ่านข้อมูลได้เพียงรู้ ชื่อผู้ใช้งาน ไม่เหมือนภาษาคอมพิวเตอร์แบบสมัยก่อน

ดังนั้นแต่ละช่องของซอฟต์แวร์ที่คุยกันจึงมีช่องว่างด้านความปลอดภัย ถูกโจมตีง่าย !!!

เน็ตเวิร์กจึงต้องมีความปลอดภัยสูง มีความเสถียรในการใช้งาน และสามารถมอนิเตอร์ได้ ต้องแน่ใจว่าไม่มีใครมาเปลี่ยนแปลงข้อมูลในการส่งระหว่างทางไปถึงผู้รับ

เมื่อ SOA คือคำตอบของการวางโครงสร้างพื้นฐานด้านไอทีแล้ว เพราะการใช้งานด้านไอที ไม่ได้จำกัดอยู่แต่เพียงการใช้ซอฟต์แวร์สำเร็จรูปเพื่อบันทึกข้อมูลของบุคลากรอีกต่อไป แต่ยังจำเป็นต้องวิเคราะห์และบริการจัดการข้อมูล และสร้างบริการในเชิงลึกอีกมาก สิ่งที่องค์กรต้องคำนึงถึงในการเลือกเวนเดอร์เพื่อเข้ามาสนับสนุนการวางระบบให้ สามารถเลือกได้ 2 แบบ คือ แบบแรก ใช้เวนเดอร์เจ้าเดียวเพื่อหาโซลูชันที่ต้องการให้ ซึ่งวิธีการนี้จะไม่มีปัญหาในการนำโซลูชันหลายๆอย่างมาอินทริเกรทกัน เพราะเวนเดอร์จะรู้ระบบและสามารถกระทำได้จากโซลูชันที่ได้เลือกมา วิธีที่สอง คือ ใช้เวนเดอร์หลายเจ้าโดยเลือกจากเวนเดอร์ที่มีจุดแข็งในแต่ละโซลูชัน แต่อาจมีปัญหาเรื่องการอินทริเกรทโซลูชัน เพราะเป็นโซลูชันจากคนละเวนเดอร์มาอยู่ด้วยกัน ดังนั้น ควรเลือก โซลูชันที่เป็นโอเพ่น ซอร์ส จะไม่มีปัญหาในการอินทริเกรท เนื่องจากเป็นซอฟต์แวร์เปิด

องค์กรใช้ไอทีในการขับเคลื่อนธุรกิจ ไม่ควรพลาดในการนำแนวคิด SOA ไปใช้ในองค์กร!!!

Source: SOA Service Oriented Architecture information at mfatix.com

HP bolsters SOA governance in Systinet 3.00

SOA Service Oriented Architecture News : HP bolsters SOA governance in Systinet 3.00

Standards support, integration with other products key to Systinet upgrade By Paul Krill

HP on Monday is updating its SOA governance software, HP Systinet 3.00, which assists with discovering and reusing services in composite applications and business processes.

Featured is support for standards such as BPEL (Business Process Execution Language) and integration with other HP SOA products. In Version 3.00, multiple users within an organization can discover and reuse services, the company said.

With the upgrade, customers can automate service lifecycle policy compliance by capturing best practices to achieve SOA objectives. This is being accomplished by integration with HP Quality Service Center, a separately available product.

Pre-built lifecycles and templates in Version 3.00 enable nonexperts to quickly use the product, HP said. More sophisticated users can customize service lifecycles through use of wizard-driven programming interfaces. Role-based dashboards provide information in a format related to a specific user's responsibilities.

HP acquired the Systinet product when it bought Mercury Interactive in 2006; Quality Center also came over with the Mercury buy. "The focus of HP SOA Systinet 3.00 is all about enabling customers to take their SOA governance efforts to a much larger scale," said Kelly Emo, HP software SOA product marketing manager.

HP has completed integrations between all of its quality solutions for SOA, she said.

Users of the upgrade can build reusable business processes and include them in the governance framework through support for BPEL. Productivity can be increased via business processes that are easier to discover and reuse, HP said.

Automation of repetitive tasks across a large number of services is featured, with support for bulk operations and lifecycle "cloning," HP said. Support for Open SCA (Service Component Architecture) and WSDL 2.0, for exposing interfaces, is featured as well.

Version 3.00 also can trigger business policies based on service quality through integration with HP Service Test Management or manage rogue services in production through linkage with HP Universal Configuration Management Database.

HP Systinet 3.00 is available now.

Source: SOA Service Oriented Architecture news at InfoWorld.com

AmberPoint extends SOA analysis software

SOA Service Oriented Architecture Articles : AmberPoint extends SOA analysis software

Transactions now can be analyzed across distributed systems by Paul Krill

AmberPoint is announcing on Monday an extension of its SOA runtime governance software to cover transactions flowing across complex heterogeneous systems.

This capability enables analysis and management of business transactions scanning distributed systems, the company said. AmberPoint is including the enhancement in the 6.0 releases of AmberPoint's SOA Management System and SOA Validation System products.

Through the extension, real-time insight is provided into business transactions. Fewer transactions fail or are lost, AmberPoint said.

"The cool thing that they have now is the ability to actually visualize a business transaction from start to finish," said analyst Anne Thomas Manes, vice president and research director at Burton group.

AmberPoint's "message fingerprinting" approach eliminates the need to modify messages, which can break dependent applications, the company said. Amberpoint. Transactions can flow unhindered.

Visibility is provided into packaged applications such as CRM, order management and billing systems that are part of composite SOA systems. As transactions progress, AmberPoint assembles message trails associated with each transaction to identify and resolve errors.

Service level agreements can be set for transactions and then managed. SOA Validation system samples and replays transaction flows against proposed changes to the production system.

SOA interactions can be tracked, including SOAP and Java Message Service calls, database calls, and RMI and EJB invocations. A library of portlets and capabilities are provided to visualize business metrics.

AmberPoint's product pricing starts at $35,000 per CPU.

Source: SOA Service Oriented Architecture information at infoWorld.com

What is SOA?

What is Service Oriented Archistecture?

เอสโอเอคืออะไร

เมื่อการแข่งขันมาถึงจุดที่การให้บริการลูกค้าเป็นสิ่งสำคัญมากกว่าการแข่งขันเรื่องราคา หรือผลิตภัณฑ์ใหม่ๆ ที่ใครๆก็สามารถทำได้ เหตุนี้ทำให้องค์กรต้องปรับเปลี่ยนรูปแบบการให้บริการเพื่อขยายให้ทันกับความต้องการของลูกค้า ตัวอย่างเช่น บริษัทผู้ให้บริการโทรศัพท์เคลื่อนที่ ในการสร้างบริการให้ลูกค้าเข้าถึงด้วยการเข้าใช้บริการผ่านร้านให้บริการ ไม่ว่าจะเป็นการเปิดบริการ ซ่อมเครื่อง รวมไปถึงสอบถามบริการผ่านคอลเซ็นเตอร์ แทนที่จะเข้ามารับบริการที่ส่วนกลาง

ทว่าระบบต่างๆที่กระจายอยู่ตามร้านให้บริการ และคอลเซ็นเตอร์นั้น ต้องพึ่งระบบไอทีจากส่วนกลางในการให้บริการ

ดังนั้น ระบบไอทีหลังบ้านจึงจำเป็นต้องสนับสนุนการทำงานที่ขยายเพิ่มขึ้น !!!

ดังนั้น แนวคิดการใช้ SOA (Service-Oriented Architecture )จึง เกิดขึ้น เพราะการใช้ไอทีในองค์กรไม่ได้จำกัดอยู่เพียงการใช้ซอฟต์แวร์สำเร็จรูป ที่ไม่เพียงพอต่อการทำงานที่เพิ่มขึ้น อีกต่อไป

SOA กระทบโครงสร้างไอทีขององค์กร

SOA ไม่ใช่ซอฟต์แวร์ หรือ แพ็คเกจ นายพัฒน์พงศ์ บุปผรัตน์ ที่ปรึกษาอาสุโสด้านธุรกิจและหัวหน้าทีมพัฒนาธุรกิจขององค์กร บริษัท เครือเจริญโภคภัณฑ์ จำกัด อธิบายถึงแนวคิดของ SOA ว่า SOA แบ่งเป็น 2 คำ Service-Oriented และ Architecture

คำแรก Service-Oriented เป็น Software ที่ไม่ใช่ซอฟต์แวร์ แพ็คเกจ แต่เป็นซอฟต์แวร์ตัวเล็ก ทำงานเฉพาะด้าน ขึ้นอยู่กับว่าจะแบ่งเป็นบริการอะไรบ้าง

คำที่สอง Architecture คือการออกแบบ โดยจะมององค์กรโดยรวมว่าต้องการบริการอะไรบ้าง ก็จะแบ่งบริการนั้นๆออกเป็นส่วนย่อยๆ

ทั้งนี้ หลายคนมองว่า SOA คือ web service แต่จริงๆแล้วไม่ใช่เพราะ web service เป็นแค่เครื่องมือในการใช้งาน

ดังนั้น SOA จึงไม่ใช่สินค้า หาซื้อไม่ได้ แต่มันคือแนวคิดที่ต้องสร้างเองในองค์กร

สำหรับสินค้าที่เกี่ยวข้องกับ SOA ประกอบด้วย 4 ส่วนคือ

Enterprise Service Bus เป็นโครงข่ายสำคัญในการขับเคลื่อน SOA ทั้งหมด เป็นการเชื่อมต่อระหว่างแอพพลิเคชัน
Design-Time Governance เป็น ดาต้า เบส กลางช่วยรวบรวมว่าองค์กรมีบริการอะไรบ้าง และช่วยนำบริการออกไปยังหน่วยงานและควบคุมบริการให้เหมาะสมกับองค์กรด้วย
Run-Time management เป็นตัวจัดการ ทำอย่างไรให้บริการทำงานสอดคล้องกับ SOA ที่ตั้งไว้ และ 4.Security Gateway ในที่นี้ไม่ได้หมายถึง Firewall ที่เป็นเน็ตเวิร์ก แต่เป็น Application Firewall ที่เข้าใจ คำสั่ง XML นอกจากนี้ต้องมี Application Delivery Control ช่วยเร่งความเร็วในการทำงานของ SOA ด้วย
เมื่อนำแนวคิด SOA เข้ามาใช้ แอพพลิเคชันแบบเก่าต้องถูกรื้อใหม่

จากแนวคิดเรื่อง SOA ทำให้เกิดการทำ Software as a service (SaaS) และ web 2.0 ขึ้น

SaaS คือ แอพพลิเคชัน แต่ไม่ใช่ แอพพลิเคชันตัวใหญ่ มีหน้าทีทำงานเฉพาะด้านในด้านหนึ่ง โดยการใช้งานของผู้ใช้ ไม่จำเป็นต้องเป็นเจ้าของแอพพลิเคชัน สามารถขอเช่าใช้งาน โดยมี Vender หรือหน่วยงานที่เกี่ยวข้องเป็นผู้ดูแลรักษา

การ์ทเนอร์ คาดการณ์ในปี 2010 ซอฟต์แวร์ทุกอย่างจะเป็น SaaS ในสัดส่วน 25%

ขณะที่ web 2.0 หลักการคือ คนใช้งานเป็นผู้จัดการข้อมูลได้ด้วยตัวเอง เจ้าของเว็บไซต์เป็นเพียงผู้ให้บริการ ไม่ใช่เจ้าของที่ทำหน้าที่ให้ข้อมูลเพียงฝ่ายเดียว การให้ข้อมูลต้องเกิดจากผู้ใช้งานและเป็นข้อมูลที่มีการสื่อสารได้ 2 ทาง

ตัวอย่างของสิ่งที่เกิดขึ้นจากแนวคิด web 2.0 ที่เห็นในตลาด ได้แก่ Blog ที่เจ้าของและสมาชิกเข้ามาแลกเปลี่ยนข้อมูลกันได้ ทำนองเดียวกับ Wikipedia หรือ Google Adsearch ที่ผู้ใช้สามารถเข้าไปควบคุมการทำงานว่าต้องการได้รับบริการรูปแบบใด

เมื่อเทรนด์เป็นเช่นนี้ องค์กรต่างๆที่ต้องการสร้างบริการให้เกิดความพึงพอใจแก่ลูกค้าจำเป็นต้องนำแนวคิดนี้ไปสร้างให้เกิดประโยชน์ในทางการตลาด

ช่องโหว่ SOA ที่ไม่ควรมองข้าม

ทว่าแนวคิด SOA ก็ต้องได้รับความปลอดภัยสูงเช่นกัน ในมุมมองของผู้ผลิตอุปกรณ์เครือข่าย อย่างบริษัท ทรีคอม (ประเทศไทย) จำกัด โดยนายสุรชัย ไชยรังกิจรัตน์ กล่าวว่า แนวคิด SOA คือการออกแบบอยู่บนซอฟต์แวร์ที่แยกกันเป็นส่วนๆ ถ้ามีซอฟต์แวร์ 10 ตัว ระบบก็ต้องรายงาน 10 ตัว ไม่เหมือนซอฟต์แวร์แบบดั้งเดิมที่รายงานรวมกันทั้งหมดเพียงครั้งเดียว

นอกจากนี้ เนื่องจาก SOA ใช้ web service เป็นเครื่องมือ ที่วิ่งอยู่บน Protocol XML ดังนั้นจึงเป็นมิตรกับมนุษย์ นั่นหมายถึงคนสามารถเข้าไปอ่านข้อมูลได้เพียงรู้ ชื่อผู้ใช้งาน ไม่เหมือนภาษาคอมพิวเตอร์แบบสมัยก่อน

ดังนั้นแต่ละช่องของซอฟต์แวร์ที่คุยกันจึงมีช่องว่างด้านความปลอดภัย ถูกโจมตีง่าย !!!

เน็ตเวิร์กจึงต้องมีความปลอดภัยสูง มีความเสถียรในการใช้งาน และสามารถมอนิเตอร์ได้ ต้องแน่ใจว่าไม่มีใครมาเปลี่ยนแปลงข้อมูลในการส่งระหว่างทางไปถึงผู้รับ

เมื่อ SOA คือคำตอบของการวางโครงสร้างพื้นฐานด้านไอทีแล้ว เพราะการใช้งานด้านไอที ไม่ได้จำกัดอยู่แต่เพียงการใช้ซอฟต์แวร์สำเร็จรูปเพื่อบันทึกข้อมูลของบุคลากรอีกต่อไป แต่ยังจำเป็นต้องวิเคราะห์และบริการจัดการข้อมูล และสร้างบริการในเชิงลึกอีกมาก สิ่งที่องค์กรต้องคำนึงถึงในการเลือกเวนเดอร์เพื่อเข้ามาสนับสนุนการวางระบบให้ สามารถเลือกได้ 2 แบบ คือ แบบแรก ใช้เวนเดอร์เจ้าเดียวเพื่อหาโซลูชันที่ต้องการให้ ซึ่งวิธีการนี้จะไม่มีปัญหาในการนำโซลูชันหลายๆอย่างมาอินทริเกรทกัน เพราะเวนเดอร์จะรู้ระบบและสามารถกระทำได้จากโซลูชันที่ได้เลือกมา วิธีที่สอง คือ ใช้เวนเดอร์หลายเจ้าโดยเลือกจากเวนเดอร์ที่มีจุดแข็งในแต่ละโซลูชัน แต่อาจมีปัญหาเรื่องการอินทริเกรทโซลูชัน เพราะเป็นโซลูชันจากคนละเวนเดอร์มาอยู่ด้วยกัน ดังนั้น ควรเลือก โซลูชันที่เป็นโอเพ่น ซอร์ส จะไม่มีปัญหาในการอินทริเกรท เนื่องจากเป็นซอฟต์แวร์เปิด

องค์กรใช้ไอทีในการขับเคลื่อนธุรกิจ ไม่ควรพลาดในการนำแนวคิด SOA ไปใช้ในองค์กร!!!

Google Chrome and SOA

Google Chrome and SOA Service Oriented Architecture by David L.

The presence of Chrome will drive much SOA in the short term

There is so much coverage around Google Chrome by the mainstream technology press that I typically don't pay much attention to these kinds of "hype-y" things until there is a reason to pay attention. I did download Chrome, installing it on the test machine in my office to see what the fuss was about and how this would affect the world of SOA/WOA. Folks, there is something to pay attention to here.

The reality is that traditional browsers, such as IE, were built from the ground up for content surfing and not application deployment and service utilization. IE put in several mechanisms to support more rich features, however the architecture of that browser meant that developers work around, not with IE.

I view the browser as really the next platform, something that will allow you to access a multitude of rich Internet applications, services, and have them work and play well together, no matter if you're on a traditional desktop, phone, PDA, or a screen in your car. Chrome seems to be a much larger leap in that direction, built from the ground up to deal with Internet-delivered applications and Web services, abstracting you away from the native operating system. At least it seems that way from my initial testing.

So, what does this have to do with SOA? Everything. SOA, at its essence, is the use of services as a way to deal with architecture. We expose services that we have been dealing with for years (legacy), we create new services, and we leverage services in the cloud that we neither own nor host. Then, we're able to create business solutions by mixing and matching services into processes and/or applications, simply put.

Thus, having a browser that is built for the use of services, Internet delivered or internal, using better operating and security mechanisms, could revolutionize the way we look at SOA. Services can be seen, thus understood, and "sex on the screen" SOA-driven applications will wow 'em in the board room.

I've always said that most SOA going on out there is through the mixing and matching of external Web-delivered services externalized through mashups, really as a way to prove the concept and to sell SOA internally. Now we have a better platform (browser) to do that.

In other words, the presence of Chrome will drive much SOA in the short term; it looks like a much better tool for the job.

Source: SOA service oriented architecture information at infoworld.com

SOA Governance Monday: More on SOA governance in the cloud

Service Oriented Architecture SOA Governance Monday: More on SOA governance in the cloud

True to form, Todd Biske took me to task for my last "SOA Governance Monday" post floating the notion of SOA governance in the cloud. He entitled his response "Governance in the Clouds? No thank you."

I hope I did not send Todd running down the hall to the datacenter to hug his server. :-) However, I suspect a lot of people in the enterprises out there have a similar take on this as Todd did, and I thought he brought up some good points, perhaps even agreeing with me on most points, as I read it.

From his post:

"I have no issues with providing a registry/repository as a service. Certainly, the querying interface must be available as a service for any company exposing service outside their firewall. Likewise, if I'm consuming many services from the cloud, it would be great to let someone else handle putting all of those services into a common, queryable location, rather than me having to establish some form of federation or synchronization between my internal registry/repository and the registries/repositories of the service providers in the cloud. This is no different than the integration problem faced by a company that builds some services from scratch, but gets others from third party products like SAP that may have their own registry/repository, like SAP ESR."
OK, so far so good. However, I'm not sure anybody would disagree all that is on the way. Indeed I was just talking to John Musser, the founder of ProgrammableWeb, who is working on a registry/directory API that does something very close to that. Thus, you'll be able to access these services using a common directory API, which will include basic SOA governance capabilities. In essence, one-stop shopping for API information, standing between the consumer of the service, and the provider. Going forward, we will see thousands of service providers, all discoverable and governed through a set of well-established APIs/services. Basic governance at first, then more advanced as time goes on.

"My constant theme on SOA governance is it is about people, policies, and process. The only role of tools is to make the processes more efficient. The cloud can only provide tooling. The degree to which you will need a registry/repository in the cloud will be completely dependent on the degree to which the rest of your tooling is in the cloud."
Once again, we agree. SOA governance should be a focus on the people, policies, and processes. I'm simply asserting that the SOA governance delivered as a service may be able to provide much more value versus on-premise, including access to common patterns and policies, the value of "as a service," and the ability to better leveraging the resources that are emerging outside of the enterprise. Thus, more effective application of the technology pattern in support of the people and the enterprise.

"While I don't think the majority of large enterprises would be willing to allow their data to be analyzed in that manner today, it won't surprise me at all if it happens in the future."
Again, we agree. There are a ton of enterprises out there who won't let any enterprise data escape their firewall. While this was the prevailing thinking just a few years ago, the acceptance of SaaS-delivered solutions such as Salesforce.com has made data living outside of the enterprise more accepted. Hopefully, SOA governance in the cloud will follow the same path, I think there is still something here.

Source: SOA service oriented architecture information at infoworld.com

SOA from the combat zone

Service Oriented Architecture SOA from the combat zone

SOA is about people, processes, and technology, but unfortunately most projects focus on the technology

Just completed my keynote presentation, "SOA in the Combat Zone," at the InfoWorld SOA Executive Summit. I thought it went well. You can find the slides here. I do have an audio recording, I'll post it somewhere.

A few things I noted:

• SOA is about people, processes, and technology. It's really divided evenly, but unfortunately most projects focus on the technology.
• Most companies are still at the experimenting stage.
• People are getting smarter around SOA, but progress is slower than I thought.
• As I told Software AG's Miko Matsumura, "It's like I'm running a fat farm, and people are sneaking in with snacks."

More to come from this conference.

Source: SOA service oriented architecture information at infoworld.com