Tag Archives: SOA Reference Architecture

by | March 19, 2013 · 5:00 AM

Gaining Greater Cohesion: Bringing Business Analysis and Business Architecture into Focus

By Craig Martin, Enterprise Architects

Having delivered many talks on Business Architecture over the years, I’m often struck by the common vision driving many members in the audience – a vision of building cohesion in a business, achieving the right balance between competing forces and bringing the business strategy and operations into harmony.  However, as with many ambitious visions, the challenge in this case is immense.  As I will explain, many of the people who envision this future state of nirvana are, in practice, inadvertently preventing it from happening.

Standards Silos
There are a host of standards and disciplines that are brought into play by enterprises to improve business performance and capabilities. For example standards such as PRINCE2, BABOK, BIZBOK, TOGAF, COBIT, ITIL and PMBOK are designed to ensure reliability of team output and approach across various business activities. However, in many instances these standards, operating together, present important gaps and overlaps. One wonders whose job it is to integrate and unify these standards. Whose job is it to understand the business requirements, business processes, drivers, capabilities and so on?

Apples to Apples?
As these standards evolve they often introduce new jargon to support their view of the world. Have you ever had to ask your business to explain what they do on a single page? The diversity of the views and models can be quite astonishing:

  • The target operating model
  • The business model
  • The process model
  • The capability model
  • The value chain model
  • The functional model
  • The business services model
  • The component business model
  • The business reference model
  • Business anchor model

The list goes on and on…

Each has a purpose and brings value in isolation. However, in the common scenario where they are developed using differing tools, methods, frameworks and techniques, the result is usually greater fragmentation, not more cohesion – and consequently we can end up with some very confused and exacerbated business stakeholders who care less about what standard we use and more about finding clarity to just get the job done.

The Convergence of Business Architecture and Business Analysis
Ask a room filled with business analysts and business architects how their jobs differ and relate, and I guarantee that would receive a multitude of alternative and sometimes conflicting perspectives.

Both of these disciplines try to develop standardised methods and frameworks for the description of the building blocks of an organization. They also seek to standardise the means by which to string them together to create better outcomes.

In other words, they are the disciplines that seek to create balance between two important business goals:

  • To produce consistent, predictable outcomes
  • To produce outcomes that meet desired objectives

In his book, “The Design of Business: Why Design Thinking is the Next Competitive Advantage,” Roger Martin describes the relationships and trade-offs between analytical thinking and intuitive thinking in business. He refers to the “knowledge funnel,” which charts the movement of business focus from solving business mysteries using heuristics to creating algorithms that increase reliability, reducing business complexity and costs and improving business performance.

The disciplines of Business Architecture and business analysis are both currently seeking to address this challenge. Martin refers to this as ”design thinking.”

Thinking Types v2

Vision Vs. Reality For Business Analysts and Business Architects

When examining the competency models for business analysis and Business Architecture, the desire is to position these two disciplines right across the spectrum of reliability and validity.

The reality is that both the business architect and the business analyst spend a large portion of their time in the reliability space, and I believe I’ve found the reason why.

Both the BABOK and the BIZBOK provide a body of knowledge focused predominantly around the reliability space. In other words, they look at how we define the building blocks of an organization, and less so at how we invent better building blocks within the organization.

Integrating the Disciplines

While we still have some way to go to integrate, the Business Architecture and business analysis disciplines are currently bringing great value to business through greater reliability and repeatability.

However, there is a significant opportunity to enable the intuitive thinkers to look at the bigger picture and identify opportunities to innovate their business models, their go-to-market, their product and service offerings and their operations.

Perhaps we might consider introducing a new function to bridge and unify the disciplines?

This newly created function might integrate a number of incumbent roles and functions and cover:

  • A holistic structural view covering the business model and the high-level relationships and interactions between all business systems
  • A market model view in which the focus is on understanding the market dynamics, segments and customer need
  • A products and services model view focusing on customer experience, value proposition, product and service mix and customer value
  • An operating model view – this is the current focus area of the business architect and business analyst. You need these building blocks defined in a reliable, repeatable and manageable structure. This enables agility within the organization and will support the assembly and mixing of building blocks to improve customer experience and value

At the end of the day, what matters most is not business analysis or Business Architecture themselves, but how the business will bridge the reliability and validity spectrum to reliably produce desired business outcomes.

I will discuss this topic in more detail at The Open Group Conference in Sydney, April 15-18, which will be the first Open Group event to be held in Australia.

Craig-MARTIN-ea-updated-3Craig Martin is the Chief Operating Officer and Chief Architect at Enterprise Architects, which is a specialist Enterprise Architecture firm operating in the U.S., UK, Asia and Australia. He is presenting the Business Architecture plenary at the upcoming Open Group conference in Sydney. 

1 Comment

Filed under Business Architecture

Tagged as , , , , , , , , , , ,

by | December 26, 2012 · 5:00 AM

Creating Reference Architecture: The Center of Excellence

By Serge Thorn, Architecting the Enterprise

This is the second installment of a three-part series discussing how to implement SOA through TOGAF®. In my first blog post I explained the concept of the Center of Excellence, and creating a vision for your organization.

The SOA Center of Excellence (CoE) will need to define a Reference Architecture for the organization.

A Reference Architecture for SOA is an abstract realization of an architectural model showing how an architectural solution can be built while omitting any reference to specific concrete technologies. Reference Architecture is like an abstract machine. It is built to realize some function and it, in turn, relies on a set of underlying components and capabilities that must be present for it to perform. The capabilities are normally captured into layers, which in their own right require an architectural definition. However, the specific choice of the components representing the capabilities is made after various business and feasibility analysis are performed. A Reference Architecture can be used to guide the realization of implementations where specific properties are desired of the concrete system.

The purpose of the Reference Architecture is reflected in the set of requirements that the Reference Architecture must satisfy. We can structure these requirements into a set of goals, a set of critical success factors associated with these goals and a set of requirements that are connected to the critical success factors that ensure their satisfaction.

A Reference Architecture for SOA describes how to build systems according to the principles of SOA. These principles direct IT professionals to design, implement, and deploy information systems from components (i.e. services) that implement discrete business functions. These services can be distributed across geographic and organizational boundaries, can be independently scaled and can be reconfigured into new business processes as needed. This flexibility provides a range of benefits for both IT and business organizations.

Using the pattern approach the SOA Reference Architecture is a means for generating other more specific reference architectures, or even concrete architectures depending on the nature of the patterns. Or to put it another way, it is a machine for generating other machines.

The Open Group SOA Reference Architecture (SOA RA) standard is a good way of considering how to build systems.

The SOA CoE needs also to define the SOA lifecycle management that consists of various activities such as governing, modelling, assembling, deploying and controlling/monitoring.

Simply put, without management and control, there is no SOA only an “experience”. The SOA infrastructure must be managed in accordance with the goals and policies of the organization, which include hardware and software IT resource utilization, performance standards as well as goals for service level objectives (SLOs) for the services provided to IT users as well as business goals and policies for businesses that run and use IT. To be truly agile, enactment of all these different types of policies requires automated control that allows goals to be met with only the prescribed level of human interaction.

For every layer of the SOA infrastructure a corresponding Manage and Control component needs to exist / be in place. Moreover, the “manage and control” components must be integrated in a way that they can provide an end-to-end view of the entire SOA infrastructure.

These manage and control functions provide the run-time management and control of the entire enterprise IT execution environment.  This includes all of the enterprise’s business processes and information services, including those associated with the IT organization’s own business processes.

The “Principle of Service orientation” must exist as defined in the TOGAF® 9.1 Framework in section 22.7.1.1 Principle of Service-Orientation, but lower levels of principles, rules, and guidelines are required.

Needs and capabilities are not mechanisms in the SOA Reference Architecture. They are the guiding principles for building and using a particular SOA. Nonetheless, the usefulness of a particular SOA depends on how well the needs and capabilities are defined, understood, and satisfied.

Architecture principles define the underlying general rules and guidelines for the use and deployment of all IT resources and assets across the enterprise. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions.

Guiding principles define the ground rules for development, maintenance, and usage of the SOA. Specific principles for architecture design or service definition are derived from these guiding principles, focusing on specific themes. These principles are the characteristics that provide the intrinsic behaviour for the style of design.

In the third and final installment of this series I will discuss how to relate SOA principles back to business objectives and key architecture drivers.

Serge Thorn is CIO of Architecting the Enterprise.  He has worked in the IT Industry for over 25 years, in a variety of roles, which include; Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Architecture and Service Management (ITIL). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

Comments Off on Creating Reference Architecture: The Center of Excellence

Filed under Cloud/SOA, Enterprise Architecture, Standards, TOGAF, TOGAF®

Tagged as , , , ,

by | October 12, 2012 · 5:00 AM

The Open Group SOA Governance Framework Becomes an International Standard

By Heather Kreger, CTO International Standards, IBM and Chris Harding, Director for Interoperability, The Open Group

The Open Group SOA Governance Framework is now an International Standard, having passed its six month ratification vote in ISO and IEC.

According to Gartner, effective governance is a key success factor for Service-Oriented Architecture (SOA) solutions today and in the future. This endorsement of The Open Group standard by ISO is exciting, because it means that this vendor-neutral, proven SOA governance standard is now available to governments and enterprises world-wide.

Published by The Open Group in 2009, the SOA Governance Framework enables organizations—public, private, large and small—to develop their own robust governance regimens, rapidly and using industry best practices. This substantially reduces the cost and risk of using SOA. As an international standard, the framework will now provide authoritative guidelines for companies across the globe to implement sound SOA governance practices.

The framework includes a standard governance reference model and a mechanism for enterprises to customize and implement the compliance, dispensation and communication processes that are appropriate for them. Long term vitality is an essential part of the framework, and it gives guidance on evolving these processes over time in the light of changing business and technical circumstances, ensuring the on-going alignment of business and IT.

This is The Open Group’s second international standard on SOA, the first being the Open Services Integration Maturity Model (OSIMM), which passed ISO ratification in January 2012. Since then, we have seen OSIMM being considered for adoption as a national standard in countries such as China and Korea. We are hoping that the new SOA Governance Framework International Standard will be given the same consideration. The Open Group also contributed its SOA Ontology and SOA Reference Architecture standards to JTC1 and is engaged in the development of international standards on SOA there.

In addition to submitting our SOA standards for international ratification, The Open Group is actively leveraging its SOA standards in its Cloud architecture projects. In particular, the Cloud Governance Project in The Open Group Cloud Computing Work Group is developing a Cloud Governance Framework based on and extending the SOA Governance Framework. This emerging standard will identify cloud specific governance issues and offer guidance and best practices for addressing them.

Finally, The Open Group is engaged in the development of Cloud architecture standards in JTC1, and in particular in the new Collaboration between ISO/IEC JTC1 SC38 and ITUT’s Cloud groups to create a common Combined Team Cloud Vocabulary and Combined Team Cloud Architecture. All of this is very exciting work, both for the SOA and for the Cloud Computing Work Group. Stay tuned for more developments as these projects progress!

Resources

Heather Kreger is IBM’s lead architect for Smarter Planet, Policy, and SOA Standards in the IBM Software Group, with 15 years of standards experience. She has led the development of standards for Cloud, SOA, Web services, Management and Java in numerous standards organizations, including W3C, OASIS, DMTF, and Open Group.Heather is currently co-chair for The Open Group’s SOA Work Group and liaison for the Open Group SOA and Cloud Work Groups to ISO/IEC JTC1 SC7 SOA SG and INCITS DAPS38 (US TAG to ISO/IEC JTC 1 SC38). Heather is also the author of numerous articles and specifications, as well as the book Java and JMX, Building Manageable Systems, and most recently was co-editor of Navigating the SOA Open Standards Landscape Around Architecture.

Dr. Chris Harding is Director for Interoperability and SOA at The Open Group. He has been with The Open Group for more than ten years, and is currently responsible for managing and supporting its work on interoperability, including SOA and interoperability aspects of Cloud Computing. He is a member of the BCS, the IEEE and the AEA, and is a certified TOGAF practitioner.

Comments Off on The Open Group SOA Governance Framework Becomes an International Standard

Filed under Cloud/SOA

Tagged as , , , , , , , , , ,

by | March 23, 2012 · 1:30 AM

The SOA RA Provides a Way to Assess or Design your SOA

By Dr. Ali Arsanjani, IBM

The Standard in Summary

The SOA Reference Architecture (SOA RA) published by The Open Group provides a prescriptive means of assessment or creation of a service-oriented architecture (SOA) solution, including the architecture for Cloud-based solutions. It does so by grouping the capabilities required of an SOA into a set of layers, each containing a set of Architectural Building Blocks (ABBs) that can serve as a checklist for an implementation of an SOA, depending on the level of maturity required by an organization. The SOA RA is intended to support organizations adopting SOA, product vendors building SOA infrastructure components, integrators engaged in the building of SOA solutions and standards bodies engaged in the specifications for SOA.

The SOA RA provides a vendor-neutral product-agnostic perspective on the logical architecture that supports the service eco-system of providers, consumers and brokers bound together by services, their interfaces and contracts.

A high level description of the SOA RA can be found above. The layers shown in figure 1 above provide a starting point for the separation of concerns required to build or assess an SOA. Each group of the separated concerns is represented by a “layer” of their own.

Starting with a robust and complete set of building blocks provided by the standard is a key enabler for the achievement of the value propositions of an SOA, such as business agility, cost-reduction, faster time to market enabled by a flexible IT infrastructure. It does so in part by providing insights, patterns and the building blocks for integrating fundamental elements of an SOA into a solution or Enterprise Architecture. 

Background

In recent years, the decoupling of interface from implementation at the programming level has been elevated to an architectural level by loosely coupling the interface of a service consumed by a service consumer from its implementation by a service provider and by decoupling the implementation from its binding. This concept is reflected in a layer in the architecture corresponding to each of these notions: i.e., a layer for services and a layer for the runtime operational systems.

This style of architecture has come to be known as SOA, where rather than the implementations of components being exposed and known, only the services provided are published and consumers are insulated from the details of the underlying implementation by a provider.

Thus, an SOA enables business and IT convergence through agreement on a (contract consisting of a) set of business-aligned IT services that collectively support an organization’s business processes and business goals. Not only does it provide flexible decoupled functionality that can be reused, but it also provides the mechanisms to externalize variations of quality of service in declarative specifications such as WS-Policy and related standards.

The SOA RA can be used as a template to be used in defining capabilities and building blocks for SOA-based solutions. This is provided by the standard as a checklist of key elements that must be considered when an SOA solution is being evaluated or architected. The SOA RA provides this through a definition of layers and architectural building blocks within those layers. The elements underlying the SOA RA is based on a meta-model defined in figure 2:

The main SOA RA abstractions, represented in figure 2 above, collectively provide a logical design of an SOA and the inter-relationships between a set of architectural building blocks residing in its layers. During Architectural Assessments or the design of a solution or Enterprise Architecture, the SOA RA provides enterprise architects with a set of architectural building blocks and their associations in each layer, the available options, and architectural and design decisions that need to be made at each layer. This allows organizations to gradually mature into the implementation of more intricate SOA designs in a gradual fashion.

In the next blog post I will describe the details behind each of the layers.

Here is a brief description of those layers as an introduction.

Brief Description of Layers

The layers that are defined in the SOA RA each provide a set of capabilities that are then realized through the use of the architectural building blocks. Note that there are five functional layers providing direct business functional value in SOA solutions. An additional four layers (Integration, Information, QoS and Governance) provide cross-cutting capabilities expected of SOA and Cloud –based solutions. A brief description of these layers is provided below:

  • Operational Systems Layer – captures the new and existing organization infrastructure and is needed to support the SOA solution at design, deploy and run time.
  • Service Component Layer – contains software components, each of which provide the implementation or “realization” for a service, or operation on a service. The layer also contains the functional and technical components that facilitate a Service Component to realize one or more services.
  • Services Layer – consists of all the services defined within the SOA. The service layer can be thought of as containing the service descriptions for business capabilities, services and IT manifestation used/created during design time as well as runtime service contracts and descriptions that used at runtime.
  • Business Process Layer – covers the process representation, composition methods and building blocks for aggregating loosely coupled services as a sequencing process aligned with business goals.
  • Consumer Layer – where consumers interact with the SOA. It enables a SOA solution to support a client-independent, channel agnostic set of functionality, which is separately consumed and rendered through one or more channels (client platforms and devices).
  • Integration Layer – enables and provides the capability to mediate, which includes transformation, routing and protocol conversion to transport service requests from the service requester to the correct service provider.
  • Quality of Service Layer – supports non functional requirement (NFR) related issues as a primary feature/concern of SOA and provides a focal point for dealing with them in any given solution.
  • Information Architecture Layer – is responsible for manifesting a unified representation of the information aspect of an organization as provided by its IT services, applications, and systems enabling business needs and processes and aligned with the business vocabulary – glossary and terms. This enables the SOA to support data consistency, and consistency in data quality.
  • Governance Layer – contains the registries, repositories, and other capabilities required to support the governance of your SOA within the SOA ecosystem and is adapted to match and support the target SOA goals of the organization.

Conclusion

The SOA RA is an excellent tool in the toolbox forEnterpriseand Application Architects.  It maps out the path for enterprise architects to assess their current SOA implementations against an industry agreed upon standard and define and customize their own internal implementations and product mappings against it.  The SOA RA provides the tools necessary to allow architects to speak in a standard, consistent vocabulary to the business line executives when designing solutions for the enterprise.  As the industry moves more towards the Cloud, the SOA RA ensures a strong foundation to pave the way towards Cloud Computing, helping businesses leverage the investments they have made in SOA services that will keep them on solid ground while moving towards the Cloud Computing Model.  Lastly, the SOA RA defines the architecture for all kinds of services based solutions, where Cloud extends and leverages services into the infrastructure in a virtualized, elastic and monitored model of pooled resources on a grander scale.

Dr. Ali Arsanjani is Chief Technology Officer (CTO) for SOA, BPM & Emerging Technologies within IBM Global Services where he leads a team responsible for developing worldwide competency in SOA/ BPM and increasing delivery excellence of SOA solutions using IBM and non-IBM tools and SOA offerings. Dr. Arsanjani represents IBM in standards bodies such as The Open Group and is responsible for co-chairing the SOA Reference Architecture, SOA Maturity Model, Cloud Computing Reference Architecture standards within that body.

3 Comments

Filed under Cloud, Cloud/SOA

Tagged as , , , , , ,

by | February 6, 2012 · 12:30 AM

San Francisco Conference Observations: Enterprise Transformation, Enterprise Architecture, SOA and a Splash of Cloud Computing

By Chris Harding, The Open Group 

This week I have been at The Open Group conference in San Francisco. The theme was Enterprise Transformation which, in simple terms means changing how your business works to take advantage of the latest developments in IT.

Evidence of these developments is all around. I took a break and went for coffee and a sandwich, to a little cafe down on Pine and Leavenworth that seemed to be run by and for the Millennium generation. True to type, my server pulled out a cellphone with a device attached through which I swiped my credit card; an app read my screen-scrawled signature and the transaction was complete.

Then dinner. We spoke to the hotel concierge, she tapped a few keys on her terminal and, hey presto, we had a window table at a restaurant on Fisherman’s Wharf. No lengthy phone negotiations with the Maitre d’. We were just connected with the resource that we needed, quickly and efficiently.

The power of ubiquitous technology to transform the enterprise was the theme of the inspirational plenary presentation given by Andy Mulholland, Global CTO at Capgemini. Mobility, the Cloud, and big data are the three powerful technical forces that must be harnessed by the architect to move the business to smarter operation and new markets.

Jeanne Ross of the MIT Sloan School of Management shared her recipe for architecting business success, with examples drawn from several major companies. Indomitable and inimitable, she always challenges her audience to think through the issues. This time we responded with, “Don’t small companies need architecture too?” Of course they do, was the answer, but the architecture of a big corporation is very different from that of a corner cafe.

Corporations don’t come much bigger than Nissan. Celso Guiotoko, Corporate VP and CIO at the Nissan Motor Company, told us how Nissan are using enterprise architecture for business transformation. Highlights included the concept of information capitalization, the rationalization of the application portfolio through SOA and reusable services, and the delivery of technology resource through a private cloud platform.

The set of stimulating plenary presentations on the first day of the conference was completed by Lauren States, VP and CTO Cloud Computing and Growth Initiatives at IBM. Everyone now expects business results from technical change, and there is huge pressure on the people involved to deliver results that meet these expectations. IT enablement is one part of the answer, but it must be matched by business process excellence and values-based culture for real productivity and growth.

My role in The Open Group is to support our work on Cloud Computing and SOA, and these activities took all my attention after the initial plenary. If you had, thought five years ago, that no technical trend could possibly generate more interest and excitement than SOA, Cloud Computing would now be proving you wrong.

But interest in SOA continues, and we had a SOA stream including presentations of forward thinking on how to use SOA to deliver agility, and on SOA governance, as well as presentations describing and explaining the use of key Open Group SOA standards and guides: the Service Integration Maturity Model (OSIMM), the SOA Reference Architecture, and the Guide to using TOGAF for SOA.

We then moved into the Cloud, with a presentation by Mike Walker of Microsoft on why Enterprise Architecture must lead Cloud strategy and planning. The “why” was followed by the “how”: Zapthink’s Jason Bloomberg described Representational State Transfer (REST), which many now see as a key foundational principle for Cloud architecture. But perhaps it is not the only principle; a later presentation suggested a three-tier approach with the client tier, including mobile devices, accessing RESTful information resources through a middle tier of agents that compose resources and carry out transactions (ACT).

In the evening we had a CloudCamp, hosted by The Open Group and conducted as a separate event by the CloudCamp organization. The original CloudCamp concept was of an “unconference” where early adopters of Cloud Computing technologies exchange ideas. Its founder, Dave Nielsen, is now planning to set up a demo center where those adopters can experiment with setting up private clouds. This transition from idea to experiment reflects the changing status of mainstream cloud adoption.

The public conference streams were followed by a meeting of the Open Group Cloud Computing Work Group. This is currently pursuing nine separate projects to develop standards and guidance for architects using cloud computing. The meeting in San Francisco focused on one of these – the Cloud Computing Reference Architecture. It compared submissions from five companies, also taking into account ongoing work at the U.S. National Institute of Standards and Technology (NIST), with the aim of creating a base from which to create an Open Group reference architecture for Cloud Computing. This gave a productive finish to a busy week of information gathering and discussion.

Ralph Hitz of Visana, a health insurance company based in Switzerland, made an interesting comment on our reference architecture discussion. He remarked that we were not seeking to change or evolve the NIST service and deployment models. This may seem boring, but it is true, and it is right. Cloud Computing is now where the automobile was in 1920. We are pretty much agreed that it will have four wheels and be powered by gasoline. The business and economic impact is yet to come.

So now I’m on my way to the airport for the flight home. I checked in online, and my boarding pass is on my cellphone. Big companies, as well as small ones, now routinely use mobile technology, and my airline has a frequent-flyer app. It’s just a shame that they can’t manage a decent cup of coffee.

Dr. Chris Harding is Director for Interoperability and SOA at The Open Group. He has been with The Open Group for more than ten years, and is currently responsible for managing and supporting its work on interoperability, including SOA and interoperability aspects of Cloud Computing. Before joining The Open Group, he was a consultant, and a designer and development manager of communications software. With a PhD in mathematical logic, he welcomes the current upsurge of interest in semantic technology, and the opportunity to apply logical theory to practical use. He has presented at Open Group and other conferences on a range of topics, and contributes articles to on-line journals. He is a member of the BCS, the IEEE, and the AOGEA, and is a certified TOGAF practitioner.

Comments Off on San Francisco Conference Observations: Enterprise Transformation, Enterprise Architecture, SOA and a Splash of Cloud Computing

Filed under Cloud, Cloud/SOA, Conference, Enterprise Architecture, Enterprise Transformation, Service Oriented Architecture, Standards

Tagged as , , , , , , , , , , , , , , , , , , ,