The definition of SOA

An article at CIO recently defined service oriented architecture as:

a broad, standards-based framework in which services are built, deployed, managed, and orchestrated in pursuit of new and much more agile IT infrastructures that respond swiftly to shifting business demands.

Also according to the article, SOA also has the potential to reduce your IT costs and improve your business agility, all while taking many of the tools already at use in the organization and conforming them to a new structure that will help align the business.

Do you agree with this definition, if not, what would you change?

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)

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”.

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?

Hiring Enterprise Architects

I came across this interesting post today regarding the hiring of Enterprise Architects. It poses the interesting question of by simply hiring and enterprise architect, does that mean that you will automatically have enterprise architecture? This blogger says no. In fact, in his opinion, many companies would like to believe that having an architect qualifies them to say that have architecture in place, but in fact there is more to the process than simply having the personnel in place. The blogger also contends that EA is a “necessary evil” and in order to hire the best architects they

“must be a dedicated and well rounded man that has to apply creatively the existing body of knowledge since the current state does not support well your endeavor to create your enterprise architecture.”

Do you think that some companies simply believe that by having an architect it means that they have an architecture? What are qualities you look for in an enterprise architect, who would need to successfully build a framework for enterprise architecture from the ground up in an organization?

EA Can Not Change the Nature of Your Business

Neil Ward-Dutton provides a different perspective of EA in his latest post on Advising on IT-Business Alignment. Neil states that even though EA is extremely effective, it is at best only shaping the way that IT supports changing business conditions and not “changing” business focus. New forces (new product launches and development, acquisitions and mergers, new regulations) will always drive business to further develop its technology focus. The best EA teams provide a way for organizations to adapt to these changes with the least amount of stress possible. Do you think that enterprise architects are realigning or “architecting” the enterprise?

Enterprise Architecture constantly leads to a competitive advantage

Paul van der Merwe, consulting manager at Real IRM recently took the time to talk about the Harvard Business study and the benefits of strong enterprise architecture. Enterprise architecture can lead to much more than a competitive advantage when it comes to your business. Along with the competitive advantage, EA can bring profits, market leadership and a sustainable business model.

The Harvard Business report showed that these were the effects of having a strong business structure:

* More competitive, especially in terms of entering new markets and launching new products and services.

* More profitable, both through increasing revenues and slashing costs.

* More easily able to embrace change, including regulatory change.

* Able to remove duplicate and redundant processes, including the IT systems which support these processes.

* Able to cut IT costs (by up to 25%), identify payback on IT and more easily merge the goals of business and IT.

* Able to manage their data more easily, with less manual rekeying of data, and reduced data error and redundancy.

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?

The Migration Planning of EA

Alin Ingis at the Chief Architect blog recently took time to discuss the third part of what he believes as the enterprise architecture cycle, the migration planning state.

He believes there are two types of migration plans:

• A formal transformation program – this will typically be a major replacement or upgrade of the IT landscape that underpins major business change
• A set of policies that steers IT change

However, there are always things that do not fall into the categories listed above. He took time to highlight the different types of business cycles that need to be observed so that they don’t disturb the practices being put into place: business cycles and business events. The three types of business cycles that Alin highlighted were: annual financial cycles, business planning cycles, and seasonal sales cycles. Companies always need to pay attention to business events, as they can occasionally put stress on some of the business processes and supporting systems.

Microsoft’s Enterprise Architecture Toolkit (EATK)

Recently, Microsoft introduced a new toolkit in order to help companies structure their enterprise architecture. Mike Walker discussed this new software application in a blog post. Thy initial form is in Alpha and they will only be offering it to a select number of users. Capabilities will include:

• Repository - Meta-data repository for uniting enterprise processes, storing existing architecture assets and a catalog for patterns (Software Factories in Microsoft terms or Architecture Building Blocks (ABB) in TOGAF ADM terms)
• Architecture Management - Portal and Workflow assets that aid in the processes and govern architecture creation through the SDLC or through post production service management processes.
• Strategy Management - Portal and Workflow that aid in the creation of as-is or current state architecture, to-be or future state architectures and the management of technology life cycles of architectures.
• Community - Portal technologies that aid in the communication and collaboration, vetting of ideals through-out the enterprise, communication of Principles, Policies, Standards and Design Patterns, Add-Ins and Templates for architecture development.
• Modeling - Usage scenarios for how to leverage Microsoft Visio to correlate architecture information from the Architecture Meta-Data Repository to Visio diagrams and shapes.

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.

How to measure the work of an EA

In a recent post at Enterprise Architecture: From Incite to Insight, James McGovern explains how the work of an enterprise architect should and shouldn’t be measured.

He states that enterprise architecture shouldn’t be measured purely based on activity and it can’t be measured from a time perspective. It also shouldn’t be based on artifacts, as these architects create many references to other architectures.

There should be no template to measure the progress of enterprise architecture. It can be measured by viewing improvements in the IT system. Another way to measure this is to look at the management of the enterprise spend, which should be spent in a strategic manner.

What do you think are the best ways to measure your accomplishments of an enterprise architect?

EA Poll

This afternoon I came across a poll in my Google Reader that caught my eye, What does your enterprise architecture group deliver? Take a second to make your selection/s, as I was shocked by the results. Here’s the direct link to the poll.

Finding the Value in Enterprise Architecture

Peter Evans-Greenwood, CTO of Capgemini Australia, released the following presentation about “Finding the Value In Enterprise Architecture” on slideshare. The presentation is very informative, and explains changes happening in Enterprise Architecture and ways to ensure that it still generates value to the organization. Hope you enjoy!

Finding Value In Enterprise Architecture

view presentation (tags: strategy capgemini enterprise-architecture ea)

Enterprise Architects can be key in tough times

Yesterday, we told you that enterprise architects are vital to an organization for many reasons.

Today, Forrester released a study stating that enterprise architects could be a valuable asset for today’s businesses given the current economic downturn. The report, detailed here at CIO, states that during this economic hardship, executives will look closely at IT and judge the value of their investments. Enterprise architects can show the executives the areas of the IT departments that can be can be let go as well as the valuable ones.

Enterprise architects should be encouraging executives to prioritize, cost quantified list of the low-impact items available for cuts, the most important things not to cust and the most valuable places to invest any remaining funds.

Another important warning from the report: Technology strategies not only had to be aligned with business goals, but that the business charges them with spotting “game-changing” technologies” and leading their organization.

It is also imperative for the enterprise architect to be a business person above all, as the technology strategies should be aligned with business goals, and the architects should lead their organization when it comes to new technologies.

Confirmation on Need for Enterprise Architecture

The need for institutions to have an enterprise architect has become more apparent, and can no longer be seen as just an opinion as I discovered in this article from Computing SA. A study conduct by Harvard Business report evaluating more than 200 companies worldwide found that companies that decided to utilize and define their enterprise architecture strategies had a significant competitive advantage. Below are the findings on the companies that participated who placed an importance on Enterprise Architecture.

- More competitive, especially in terms of entering new markets and launching new products and services.

- More profitable, both through increasing revenues and slashing costs.

- More easily able to embrace change, including regulatory change.

- Able to remove duplicate and redundant processes, including the IT systems which support these processes.

- Able to cut IT costs (by up to 25%), identify payback on IT and more easily merge the goals of business and IT.

- Able to manage their data more easily, with less manual rekeying of data, and reduced data error and redundancy.

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.

Role of an Enterprise Architect

I came across an interesting post on the IT Knowledge Exchange from Anton Venter in which he describes what the ideal role of an Enterprise Architect should be. One of the important factors of an enterprise architect is the ability to hold both a macro and micro view of business strategy. An architect must have knowledge of the architectural approach (macro view) and must also be to work with individual projects (micro view), merging both views together for successful implementation.

Today’s enterprise architect must understand business problems and know what technology is needed in order to provide solutions for it. What’s your take on the role of an enterprise architect?

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?

What exactly is EA?

If you are searching the web for a description of Enterprise Architecture, chances are you will come across various translations. This is because there is not one set definition for EA. I’ve encountered this handy list of different interpretations of Enterprise Architecture compiled by Roger Pedroso across various sources at the IT Knowledge Exchange. I’m sure you’ll find it just as useful. Here’s the list:

1. Enterprise Architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks.

2. An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization.

3. The EA is:
What: The structure of an Enterprise and its blueprint describing.
How: How the Enterprise operates and the processes executed by.
Whom: People.
Which: The technology implementing processes.
Where: Showing the location of people and technology.
Why: To streamline, align, blueprint, strategically plan, and confer agility.
When: According to the Enterprise transformation plan to a target state.

4. Enterprise architecture is an agency-wide framework for incorporating business processes, information flows, applications, and infrastructure to support agency goals.

5. Enterprise architecture is the organizing logic for business processes and IT infrastructure.