Growth of SOA in India

Business Standard mentioned today, in this article, that India is expected to have the “fastest growing SOA market in the Asia-Pacific region”. Springboard Research has predicted that this market will have a compound annual growth rate of 49% from 2006 to 2009. Many organizations are already starting to seize this opportunity. Intelligroup, one company interested in this growth rate, believes that 20% of the “larger SAP customer in India” will be adopting SOA within the year. Liladhar Bagad, practice head of Intelligroup, released this statement as a means to explain this growth:

“As organisations become more global, SOA will become an integral part of their strategy. It is aimed at lowering the total cost of ownership, simplifying integration and customisation. Organisations are increasingly embracing SOA as a means to access and distribute information in real time”

It is cautioned, however, that organizations need to be aware of disappointment that some companies may announce. As Chandika Mendi, director and head of Virtusa Corporation, explained

“The reason for the disappointment will be due to taking a much narrowed approach while defining SOA, which could lead to failure of implementations. Also, the initial investment in SOA is high and will reap benefits slowly as the entire enterprise moves to it, which is a fairly long journey,”

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Adopting SOA: More than just getting the software

In a recent article at CIO, Ty Anderson discuses how adopting SOA into the business is like buying a total home gym. Buying it doesn’t get the job done, it’s important to use the purchase continually in order to get the benefits the software can offer.

-- It’s important to audit existing applications. See what the processes are for your current business processes. Know what you’ve got so you can start in the right place.

-- Make the services as simple as possible

-- Work with your SOA tools every day. You’ve got to continually work towards the adoption, day in and day out to find out how the software truly works.

-- Keep working – Now that you’ve got SOA, it’s important to keep it current. Learn what’s new in the software and implement additional tools that are beneficial to your company.

And throughout the whole process, have someone there to keep you going in the right direction. A mentor can help you achieve your goals and keep you working towards the benefits of SOA.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

The IT and Business Divide

In this article the pIT stop panel was interviewed about the possibility of enterprise architecture in bridging a gap between the IT and business divide. Their answer was

“If I had a polo mint for every time I heard that a technology or approach would provide “alignment” between IT and the business I would walk around with permanently fresh breath.”

While they say there is no easy fix in bridging the divide, they did say that this did not negate the importance of “establishing formal ‘enterprise architecture’” They said that they have seen improvements in IT and business alignment especially in terms of SOA. One piece of advice they gave was to start small. In addition, they mentioned that instead of simply relying on technology or an approach, it is important for organizations to understand the importance of “human factors”.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Start Small for SOA

This article brings up an interesting point that it may be best to start small when it comes to introducing SOA to an enterprise. While the initial reaction maybe to begin with projects that are high profile, oftentimes without the cooperation from the IT and business departments such projects have the potential to lead to frustration, and ultimately may make individuals feel that SOA failed. To prevent this feeling, it could be beneficial to start on smaller projects where there is plenty of cooperation in order to build “momentum”. With one successful project, it becomes easier to show the benefits in order to gain cooperation on the second, and thereby gaining trust in the usefulness of SOA for organizations.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Carphone Warehouse sees benefits to SOA

As reported by this article at CIO, Carphone Warehouse, a mobile phone retailer in the UK, moved to SOA in 2005. Even though they saw immediate benefits, there were other things that were still falling behind in their IT system. There were still 53% of new service designs that were failing governance tests the first time and there was still duplication in some of the services performed.

As a result, they adopted HP Systinet. This SOA governance tool helped 95% of new service designs pass the governance test. It has also estimated that this new software will save them £526,000 over the next three years, due to the avoidance of duplicating processes. It also will allow the IT department to deliver new services to the business in the shortest amount of time possible.

Do you think that corporations selling SOA governance tools are starting to respond more to customers needs?

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

SOA Presentation

Recently I saw this interesting slideshare presentation that discusses Service Oriented Architecture titled “The Service Oriented Elephant”. Some of the main points that it covers include: Building Blocks of SOA, Organization Roadmap – How much SOA, and Implementation scenarios. Take a few minutes to go over this and let us know your thoughts. Do you have any observations or musings regarding the presentation?

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Service Oriented Elephant

view presentation (tags: enterprise architecture service orientation web services soa)

The Government’s Incremental Move Towards SOA

This latest post on the SOA Network details how the latest report from Input, a leader in the authority of government business, discusses that the government’s growing adoption of SOA practices will fundamentally change how it delivers internal citizen-facing services. The federal market can benefit from increased agility and better IT alignment that SOA brings to the table.

Deniece Peterson, senior analyst at INPUT mentions:

"SOA shifts the concept of the application into a highly dynamic and fluid marketplace of plug-and-play services. A function previously performed by one vendor's application could now be completed by a number of discrete services provided by a multitude of providers. The standardized environment required to make this happen could severely impact the provider who relies heavily on proprietary elements for competitive advantage."

It is still early in the process to see a dramatic change in the federal SOA market as SOA solutions are slowly being integrated into the customer’s environment. The findings from Input can be found here, “Service-Oriented Architecture: Implications for Government and Industry”.

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

At CIO, they recently profiled a chapter from the book Executing SOA: A Practical Guide for the Service-Oriented Architect. SOA can result in the collaboration and a change in the system both affects the workers and the management of the system. Changes in the system can mean behavioral changes in employees and management and changes in the roles of all employees, with cooperation of all parties a high priority.

This article defines the following as important for service oriented people in the enterprise. Here’s the list from the book about managers:

• Primarily act as observers instead of directors (who issue top-down orders).
• Monitor the business (adequate tools and systems support this).
• Define rules and processes, such as building a constitution that includes the fundamental laws for the company (golden rule or constitution).
• Recognize talents and temperaments as well as know the skills of the employees to staff roles/pools (act as mentors for personal development—especially matching talents and temperaments, not just acquired skills and experiences, to the tasks).
• Allow satisfying freedom to the employees under the set rules (equivalent to the loosely coupling of services in an SOA).
• Motivate employees by addressing the individual talents and preferred tasks. (This applies especially to people managers who are responsible for dedicated teams, versus business generals who are in charge of the overall corporate directions and are not dealing with daily execution at the bottom.)

Do you agree with all these points? Would you add any?

We're getting ready to launch a new blog that looks at the broader issues of Enterprise Architecture, update your RSS feed now as we get it ready for our official launch: http://evolveea.blogspot.com/

Reasons Why People are Responsible for SOA Failure

Mike Kavis from Techworld posted this informative article on what makes SOA fail in businesses. In summary he provided these 10 reasons of why people are responsible for the failure:

1. Fail to explain SOA’s businesses value
2. They underestimate the impact of organizational change
3. They fail to secure strong executive sponsorship
4. They attempt to do SOA “on the cheap”
5. They lack the required skills to deliver SOA
6. They have poor project management
7. They think of SOA as a project instead of architecture
8. They underestimate the complexity of SOA
9. They fail to implement and adhere to SOA governance
10. They let vendors drive the architecture

It was interesting to see his opinion on what needs to change in the way in which people incorporate SOA into their respective organizations. What are your viewpoints on what makes SOA work in the workplace? Can you think of any improvements you would recommend for individuals within companies?

SOA and the enterprise

In an article I found at Computer World, three experts talk about importance of implementing SOA on a company wide basis, not just a project to project basis, and defining the processes to have the enterprise architecture work company wide. Larry R. DeBoever, one of the principals, along with Tim Westbrock and George S. Paras, of EAdirections took time to share their views on what they see necessary for SOA to be best implemented across an enterprise.

Westbrook believes architecture is important to the processes, "A strong enterprise architecture program is vital if SOA is to reach its potential of actually operating across the enterprise rather than being isolated in individual custom application development projects."

Paras belives, "Many people see SOA as a technology, an implementation approach you use deep in the bowels of application development. It really is more of a flexible, adaptive, reusable design approach for disassembling and reassembling an enterprise as it evolves in response to a constantly changing environment."

It is important that the SOA plan of the company is built off of a game plan, as it is vital to know which services need to have processes built for them and how they’re going to be coordinated together. All of this and standards need to be the same across the company in order for SOA to work to the best of its ability.

Details of What is Not SOA

Enterprise Architecture, SOA, and other phrases like it have become buzzwords within corporations today, yet sometimes I still find myself struggling to understand the terms. Earlier today, however, I came across this blog post, which discusses how to determine when something is not SOA. Below is the checklist that I found to be helpful:

1) If a vendor tells you that you need to buy a suite to get to SOA… it’s not SOA. SOA means complete freedom from suites and integrated packages.

2) If a vendor is trying to sell you hardware… it’s not SOA. Enough said.

3) If you’re sending out email inquiries or making phone calls to find out what services are out there…. it’s not SOA. Registries and repositories are essential for service discovery and validation.

4) If nobody’s sharing services… it’s not SOA. You can have all the standardized services you can handle, but if it’s services within silos and nothing more, then it’s services in silos.

5) If developers and integrators are not being incented or persuaded to reuse services and interfaces… it’s not SOA. Without incentives or disincentives, they will keep building their own stuff.

6) If your CIO is clueless about what’s going on with shared services… it’s not SOA. To truly function, SOA-based infrastructures need to cross organizational boundaries, and it takes someone at the management level to bring these efforts together. Otherwise, again, it’s services in silos.

7) If the IT department is running the whole show… it’s not SOA. Sorry IT folks, but SOA needs to have the business heavily involved in the effort as well.

8) If it only runs one operating system or platform… it’s not SOA. SOA has nothing to do with any single OS.

9) If it replicates a SOA in place elsewhere… it’s not SOA. Every company has unique business requirements and processes, and no two SOAs will be alike.

10) If you have to rewrite or redesign code to make things run right… it’s not SOA. SOA is supposed to make rewrites unnecessary.

Why do many IT professionals reject Process Oriented Approaches like CMMi?

I recently came across James McGovern’s latest post on his Enterprise Architecture blog where he explains why IT practioners tend to stay away from CMMi. Software developers are generally used to some kind of structure when dealing with open source; CMMi lacks rigorous structure and so it might be difficult for developers to understand. What’s your experience with dealing with process oriented approaches?

Revisiting the Promise of SOA

As part of this blog, we like to bring you the latest up to date information from across the EA industry. If you didn’t get a chance to view the latest webinar yesterday brought to you by EAC, here’s a great opportunity to view the archived recording of “Revisiting the Promise of SOA” presented by Peter Salvitti of Collaborative Consulting. In this webinar you can expect to learn:

• Whether the adoption rate of services is deep or wide (i.e., related to specific business need or simply a technical service)
• Where reuse is gaining traction in organizations
• How to fund your SOA initiative and who is paying for what
• The fundamental building blocks that should (must?) be in place
• How to navigate vendor marketing

Definitely take the time to view it at your own leisure as I’m sure you’ll find the information very valuable.

SOA: What are the emerging Challenges?

In a recent interview at SOA News, Brian Nally sat down with Rami Jammour to discuss what’s happening in the world of SOA. Nally asked what some of the emerging quality challenges for SOA were.

Nally responded with two things:

1) Environments are more and more heterogeneous, with many different faces and protocols

So, having said that given that situation, when you talk about quality you have to make sure that your business processes run on top of these heterogeneous environments need to be validated. You need to have a framework that is flexible enough to drive your process and drive your testing activities across these different heterogeneous environments.

2) People became more familiar with the processes, they began to look at the end processes.

So, they start to ask, what about my legacy applications, or the mainframes, or the green screen? They look more at what kind of framework can give them the flexibility so it can be extended to help them with all these specific needs that they have. Having a framework that is extensible and that can support some of the common things that people do is becoming more and more critical.

What do you personally seee as the emerging challenges for SOA?