Business Analysts
Business analysts are tasked by their organizations to close the gap business objectives and IT restraints. This blog provides the SOA community with a forum for best practices. If you are interested in contributing, write to us at centrasite-info@infoq.com.
The Human Side of SOA
The way that we have built applications and their architectures have evolved greatly over the last 30 years of computing; shifting back and forth from proprietary character mode terminals with centralized processing to client-server applications with distributed processing back to centralized hosting of applications, but this time with open, standards-based web-delivered front ends. Each of these trends have included a variety of methods to connect disparate systems - many proprietary, some without any reusable characteristics, and all typically requiring the developers, operators and maintainers to learn a new set of skills and the organization to put new processes in place. These upheavals invariably create friction and pain for the individuals and the organization involved.
If SOA is the answer - what was the problem?
Submitted by cfs. Business Analysts
During one of my presentations I have been asked by an alert and sceptical participant the (for SOA evangelists almost heretical) question.
If SOA is the answer - what was the problem?
And as I recovered from my struggle and stuttering on stage - can't remember what exactly I said but I survived - I realized that this seemingly simple question certainly deserves a good answer. However, I would have to do some real thinking in order to arrive at a satisfactory solution.
And here is my answer:
SOA solves (i) future integration problems or (ii) future flexibility problems of organizations with an (iii) irreducibly complex IT/IS environment.
Typical SOA Scenarios
Submitted by Ivo Totev. Business Analysts
A Service-Oriented Architecture, or SOA, is a highly promising concept for organizations today. It supports realization of their key business goals, such as improve customer service, cut costs and penetrate new markets. However before embarking on a SOA project, organizations need to define and plan their overall SOA direction, starting with these three questions:
What business challenges do you want your SOA to address?
How will you organize your SOA project and manage internal communications?
How do you plan to measure the success of your SOA efforts?
What Possibilities does Web 2.0 Offer for SOA Projects?
Submitted by Ivo Totev.Business Analysts
The way we use the Internet is in a state of transition. Now more than ever people employ the Internet to share ideas and collaborate on projects and content. The term "Web 2.0" refers to an evolving Internet, reflected today by wikis, weblogs and video portals. Service Oriented Architectures (SOA's), on the other hand, support business processes.
First-generation SOA projects were primarily dependent on middleware, and end user integration was a notion still in its infancy. Now SOA is moving closer and closer to the user - with a strong emphasis on rich semantic content, ergonomics, usability and availability via a browser. It is, after all, the users who should benefit the most in their daily work from the processes and services offered by SOA. Particularly in an enterprise context, a Web 2.0 approach enables better user interface information integration, even on a semantic level, going significantly further than was ever the case with the Internet.
Is SOA soon to be a commodity?
Submitted by Ivo Totev.Business Analysts
SOA is about to reach a new level of maturity, according to Jason Bloomberg, IT analyst at Zapthink. He predicts that by the end of this decade, SOA best practices will be widely spread and accepted, making service orientation a commodity.
As SOA is a multi-layered architecture, the answer to the question above (Is SOA soon to be a commodity?) depends on which level is being observed at that particular moment.
The technological foundations of an SOA - like the basic standards, middleware and architectural service design models - have already reached a considerable degree of maturity. This is why topics like these will most likely play only a minor role in any discussions on SOA.
ESB is merely a starting point for SOA
Submitted by Thomas G. Business Analysts
As the market continues developing the big picture about SOA, many constituents are becoming concerned about the practical issues: how to design a plan to build an SOA, how to identify the business problem, how to build services, and, of course, how to then figure out the infrastructure.
SOA - what exactly are we talking about?
Submitted by Ivo Totev.Business Analysts
What was it I recently read in the press? An ERP company's user group survey revealed that only a small percentage of its clients were involved with SOA. This immediately prompted the question - is SOA real or just a lot of hype with no substance?
What had happened? The company's marketing department had decided to give a new name to its SOA strategy, "Enterprise SOA". Had they been a little more precise and called it "Enterprise Resource Planning SOA", there would probably have been no cause for discussion at all. For in this case, it would have been clear to everyone that this SOA meant some kind of large-scale project - namely major software re-design. By the way, this is not a particularly simple job achievable in a day; it applies to all large-scale projects, even the Airbus 380. Large-scale projects like these all have something in common - the client takes on a passive role. Whether we all will be flying in an Airbus 380 in a few years' time or deploying an entirely SOA-based ERP depends on how good are the particular companies' project teams. All we can do is sit back and cross our fingers that everything will go well, making the reservations of the user group mentioned earlier quite understandable.
A Learning Community for SOA
Submitted by Thomas G. Business Analysts
SOA is entering the next phase in its maturity: Primetime. Enterprises that adopted SOA early are showing first results, and the competition is accelerating, catching up to do the same. However, an enterprise cannot be educated, only the people who make up the enterprise can be educated. The enterprise consists of many different people with different job roles and various education levels, especially in regards to IT-related topics like SOA. A recent article in VNU discusses how different enterprise staffers have greatly varying knowledge levels about SOA.
SOA Governance - it's not just a question of services
Submitted by Ivo Totev. Business Analysts
The main objective of SOA is to bring business and IT closer together. SOA governance helps achieve this aim by organising the right processes for a company. The present debate on governance, however, seems to be centred exclusively on services. Of course we have nothing against services - after all, they in fact form the modular building blocks of any SOA set-up. The problem is, if you only bear services and their implementation in mind, you tend to lose sight of the "big picture" and the essential business overview. So why not think on a grander scale? Let's take for instance something really big - a business domain; for example: payment transactions, logistics or a call centre.
ESB - the very heart of every SOA. Is it really necessary?
Submitted by Ivo Totev. Business Analysts
Easy and simplified answers are de rigueur at the moment - and "ESB" is exactly the kind of answer you might get when asking about a SOA. Don't get me wrong-an ESB is a very valuable and useful component in a SOA set-up. If, however, you think that you are perfectly prepared for setting up a SOA simply because you now have at last got the selection process for your ESB over and done with - then you had better think again.
There is another view - although an ESB does not equal a SOA, it is however at its very heart. While this answer may be incrementally better, it doesn't quite capture the essence of what a SOA really is: a SOA's main task is to chop up the IT world into small tidbits. These tidbits are designed in line with the individual wishes of the specialist departments, correspond to industry standards and can be combined to form new processes and applications. They have to communicate with each other, exchange information, transform it and then forward it securely. There is also the need to link these tidbits with larger ones, bringing us to the topics of orchestration and composition. And this is where an ESB can actually be of help.
InfoWorld: A Product Management Approach to SOA
Submitted by sfroman. Business Analysts, System Architects
By InfoWorld's David L. Margulius
"Deploying an enterprise-wide SOA is not just about developing and deploying components and services -- it's about changing the DNA and culture of IT to become more product-management oriented."
Read the article in InfoWorld.
System Architects
System Architects are tasked by their organizations to close the gap between IT and business objectives. This blog provides the SOA community with a forum for best practices. If you are interested in contributing, write to us at centrasite-info@infoq.com.
The role of SOA Governance in Legacy Modernization - Part 1
Submitted by John Fitzgerald. System Architects
Legacy modernization, through service-enablement of legacy systems, is a key driver in helping organizations implement a Service-oriented Architecture (SOA). However, legacy modernization should always go hand-in-hand with SOA governance. Presuming that a decision has been made to pursue service-enablement, the good news is that developers and even business users now have a number of tools at their disposal to open up legacy systems. This is also the bad news.
With various tools (in skilled or unskilled hands) producing services in different ways and based upon different legacy system layers, the potential is strong for a disorderly mish-mash of services popping up throughout the organization. Below are five problem areas that could appear when an unmanaged herd of new services works its way into the company's SOA projects:
Business Transformation Conference
Submitted by kswenson. System Architects.
I just spent a week in Washington DC at the Business Transformation Conference put on by Transformation+Innovation. It is a small conference, but an amazing collection of speakers. For example:
- Dennis Wisnosky who is the Chief Technology Officer of the Department of Defense and he talked about his challenges of using SOA and BPM to transform the IT infrastructure of a $500B organization. One key point he made was to "work with platoons (8 people), not battalians."
- Dale Meyerrose, the Associate Director of National Intelligence and Chief Information Officer, spoke about efforts to integrate informations systems across the intelligence agencies. He says "ultimately, all problems are people problems." He also gave the advice: "Think Big, Start Small, Fail Small, Fail Small, Fail Small, Succeed Small, Scale Fast."
- Paul Strassman, the George Mason University Distinguished Professor of Information Sciences, (Former Chief Information Officer of Xerox) spoke about how HP was using SOA to cut the total number of enterprise applications deployed to one quarter as many, decreasing IT budget spend, while at the same time being more productive. Did you know that HP is now bigger than IBM?
- Jon Pyke, president of Process Factory gave an entertaining talk about refocussing business processes back on humans. He used the first six minutes of his speach to play a video which everyone should really watch, and think about: http://www.mkpress.com/ShiftExtremeGoogle.html.
BPM and SOA - Marriage that will end up in divorce if not done correct
Submitted by orajiv. System Architects
BPM promotes model based definition that ensures business gets exactly what they ask for. BPM enables business to identify what IT services are required to automate their business processes. So from my perspective, BPM centric approach helps to avoid wasting time, resource and cost by identifying the portfolio of service components that are required to be truly exposed as "services". What i have read and heard so far is that SOA vendors propoganda about the need for "service enabling" all the IT applications. What is the point of creating 1000's of services if only very few are needed by the business, infact in certain cases you find the one that really had to be built as service do not exisit. SOA today is seen as an IT initiative to respond quickly to changing bussiness requirements. But I strongly belive that SOA should be a business driver because business understands the process, and once process is mapped out it clearly identifies what IT services are required to accomplish those business goals. This information should then be used by IT to prioritize their SOA projects and not the other way around.
SOA and Governance
Submitted by John Fitzgerald. System Architects
When we look at application development, there are typically two camps involved - the users of the applications and the developers who build them. In the past, these groups only interacted when they had to - i.e. something need to be built or something had to be fixed.
Historically, application development can be summarized like this: users identify a need for a new application. The developers receive a set of requirements and start building the application. Developers integrate existing and new applications, sometimes with chewing gum and duct tape, and deliver a new application (that is often outdated and inflexible).
InfoWorld: A Product Management Approach to SOA
Submitted by sfroman. Business Analysts, System Architects
By InfoWorld's David L. Margulius
"Deploying an enterprise-wide SOA is not just about developing and deploying components and services -- it's about changing the DNA and culture of IT to become more product-management oriented."
Read the article in InfoWorld.