SOA needs supporting architecture

Dan Rosanova recently wrote a post at CIO about how many companies often adapt SOA because it is what many companies are interested in when starting architeture. However, he notes that while SOA is a good thing, it may not perform to its higest potential if there aren't other architectural software structures in place to support it. Read the full article here.

SOA is dead

Anne Thomas Manes recently declared SOA dead. This failed experiment was suppose to reduce companies costs and increase their agility. But as we've seen the economy fall, it has not held up to its promises.

The demise of SOA is tragic for the IT industry. Organizations desperately need to make architectural improvements to their application portfolios. Service-orientation is a prerequisite for rapid integration of data and business processes; it enables situational development models, such as mashups; and it’s the foundational architecture for SaaS and cloud computing. (Imagine shifting aspects of your application portfolio to the cloud without enabling integration between on-premise and off-premise applications.) Although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever.

What do you think about the current state of SOA? Is it indeed dead?

What is the role of a Enterprise Architect in a programme?

This post on CIO Knowledge Base explains how an enterprise architect is not needed if enterprise architecture is present and a manager is simply trying to ensure that a new project will fit with the existing architecture. On the other hand, if the project involves changes a scope of the enterprise architecture, then managers will have to consult with the enterprise architect. Program managers have the ability to monitor implementation of enterprise architecture as long as no changes needed to be made to the infrastructure itself. How does your company define the role of an enterprise architect in a progamme?

LiquidHub Not Slowing Down

While many companies are going through hiring freezes as a result of the current economic upheaval, LiquidHub has a different point-of-view as remarked on here. Mr. Jonathan A. Brassington, CEO of LiquidHub, had this to say:

Inspite of the cautious global business environment the company has a robust order pipeline and is hiring aggressively both in the US and in India. LiquidHub sees a great opportunity in the current downturn based on its Enterprise Architecture philosophy where clients can "do more with less"

What philosophy is your organization subscribing too? Is Enterprise Architecture helping to whether the storm?

Apache Tuscany Enables SOA solutions to More Easily Respond to New Business Requirements

The SOA Network reports that Apache Tuscany has released version 1.3.2 of its Service Component Architecture (SCA) for Java.

Apache Tuscany provides a dependable infrastructure for deploying, running, and building SOA solutions as well as addressing real business problems posed by SOA. Anthony Elder, ASF Vice President and Chair of the Apache Tuscany Project Management Committee mentions:

"Over the past two years, the Tuscany community has focused on developing fully open, standards-based, large-scale SOA solutions. We continue to receive enthusiastic support for Tuscany's simple, highly extensible Service Component Architecture (SCA), Service Data Objects (SDO), and Data Access Service (DAS) subprojects. Becoming an ASF Top-Level Project and great ideas for future development -- including improvements in application server integration, distributed runtimes and Web 2.0 support -- underscore how Tuscany continues to go from strength to strength."

It will be interesting to see how this infrastructure will play out in the upcoming months.

Synovus Financial Adopts EA

Recently, Synovus Financial won an award for successfully implementing SOA from CIO Magazine and SOA Consortium. Their goal was to create a secure vault payment platform and an Automated Clearing House payment program. To find out more about how they were able to successfully implement SOA properly, please read the article here.

SOA Governance Book

Ever wondered about SOA Governance? Well according to this article AgilePath CEO Eric Marks has released the first ever SOA Governance book, and, it's free. Titled "SOA Governance for the Services Driven Enterprise", it is the third book that has been released by AgilePath discussing SOA topics of interest. As Eric Marks, CEO and author of the book remarked:

"AgilePath is pleased to once again lead the SOA industry forward with proven approaches to solving SOA challenges. This book is the industry's first SOA governance book, and that is no surprise. SOA governance is a challenging issue, and few SOA practitioners truly understand the subject's richness, complexity and depth. This book will provide much-needed guidance for the many facets of enterprise SOA governance."

EA is in Demand

This post on SearchSoa.com highlights how there is a huge demand for IT professionals with skills and certifications including project management and enterprise architects due to service-oriented architecture.

David Foote, CEO and chief research officer for Foote Partners mentions:

"SOA is a huge collection of skills. There's a lot to SOA so it's a very, very broad category."

This has caused companies to seek architects who not only understand SOA, but those who also have knowledge of business models and understand specific corporate culture.

SOA -- Is it really a business problem?

Joe McKendrick at ZD Net recently pointed out that most businesses believe SOA is purely an IT problem. Jeff Schneider is one of those who agrees:

“Sure, I.T. problems, like HR or garbage collection, may bubble their way up to become a business problem, but at the end of the day I.T. has to figure out how to do their job and go do it. When the janitor picks up the trash in my office they do it in the most efficient way they know how. They don’t ask ‘the business’ if they should do it efficiently - they just do it. When did I.T. become such wussies?”

So how do we overcome this potential road block in implementing SOA into the enterprise? Offer solutions that include SOA for business problems. SOA as a be all and end all solution might not work well, but showing the value of certain proponents will work well for the enterprise.

MapReduce moving into enterprise architecture world

MapReduce is a Google-inspired program looking to help enterprises clean up their databases and put them into the clouds. SearchSOA.com recently took a look at it here. This was a program originated by Google programmers who wrote programs for parallel situations, so data use was properly transferred from program to program. It also analyzes both structured and unstructured data.

Rich Seeley of SOA Situations can be useful in three situations:

- Text tokenization, indexing, and search

- Creation of other kinds of data structures (e.g., graphs)

- Data mining and machine learning.

What is WOA

This article from cnetnews.com states: Web-oriented architecture (WOA), a descriptive term for a subset of service- oriented architecture (SOA), has recently arisen as the next buzz-phrase to help further confuse the IT architect. So what is it? The article explains that WOA is an implementation of SOA that utilizes representational state transfer resources that permit data and services to be utilized through a uniform resource identifier. Another explanation comes from Nick Gall from Gartner:

WOA is an architectural style that is a substyle of SOA based on the architecture of the www with the following additional constraints: globally linked, decentralized, and uniform intermediary processing of application state via self-describing messages.

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.

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?

Service Oriented Elephant

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

Human Side of SOA

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?

Supporting SOA

This article from Collaborative discusses funding of SOA. As the article states, before commencement of a project of this kind it is important for organizations to consider their investment principles, current assets, and option that they have for IT funding. Some other highlights included in this article is that to succeed with funding it is imperative for an SOA initiative to

align with one or more core investment principles, such as:

1. Enterprise Vision & Mission Alignment
2. Enterprise Mission Criticality
3. Enterprise Economy-of-Scale Value
4. Enterprise Risk Tolerance
5. Strategic Leadership Opportunity
6. Interoperability
7. Common Need
8. Technology Maturity

The paper also informs that the basic funding models include:

1. Project-based

2. Enterprise-based

3. IT-based

4. Charge-back

I found the overall article to be very helpful in providing a focus when discussing the need for funding of SOA projects and recommend it for reading.

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?

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.