Category Archives: Cloud/SOA

The Open Group Cloud Computing Work Group Web Jam on CIO Priorities

By E.G. Nadhan, HP

Recently, I shared my experience leading the first Web Jam within The Open Group Cloud Work Group. We are now gearing up to have another one of these sessions – this time around, the topic being CIO priorities as driven by Cloud Computing. Even though the Web Jam is an internal session held within The Open Group Cloud Work Group, we want to factor in other opinions as well – hence this blog where I share my perspective on how Cloud Computing is defining the priorities for the CIO. I am basing this perspective on the findings from a survey conducted by IDG Research as published in this white paper on IT priorities where I was one of the persons interviewed.

I would categorize the CIO priorities across five drivers: customers, business, innovation, finance and governance.

1. Customers. CIOs must listen to their customers (especially shareholders). Cloud Computing is breeding a new generation of customer-focused CIOs.  Shareholders are driving IT to the Cloud. At the same time, enterprises need to be at least as social as their customers so that they can process the brontobytes of data generated through these channels.

2. Business. CIOs must shift their attention from technical matters to business issues. This is not surprising. As I outlined in an earlier blog post, the right way to transform to Cloud Computing has always been driven by the business needs of the enterprise. When addressing technical requests, CIOs need to first determine the underlying, business-driven root cause of the request.

3. Innovation. CIOs must make innovation part of the IT blood stream. CIOs need to take steps today to innovate the planet for 2020.  For example, the Cloud facilitates the storage of brontobytes of data that can be informationalized through data analysis techniques by those who have the sexiest job of the 21st Century – Data Scientist.

4. Finance. CIOs must have the right mechanisms in place to track the ROI of Cloud Computing.  As fellow blogger from The Open Group Chris Harding states, CIOs must not fly in the Cloud by the seat of their pants.  Note that tracking the ROI is not a one-time activity. CIOs must be ready to answer the ROI question on the Cloud.

5. Governance. CIOs must ensure that there is a robust Cloud governance model across the enterprise. In the past, I’ve explained how we can build upon SOA Governance to realize Cloud governance.  As a co-chair for the Cloud Governance project within The Open Group, I have a lot of interest in this space and would like to hear your thoughts.

So, there you have it. Those are the top 5 priorities for the CIO driven by key Cloud Computing forces. How about you? Are there other CIO priorities that you can share? I would be interested to know and quite happy to engage in a discussion as well.

Once the web jam has taken place, I am planning on sharing the discussions in this blog so that we can continue our discussion.

NadhanHP Distinguished Technologist, E.G.Nadhan has over 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project and is also the founding co-chair for the Open Group Cloud Computing Governance project. Twitter handle @NadhanAtHP.

2 Comments

Filed under Cloud, Cloud/SOA

First Open Group Webjam — Impact of Cloud Computing on our Resumes

By E.G. Nadhan, HP

The Open Group conducted its first ever webjam within The Cloud Work Group last month. A Webjam is an informal mechanism for the members within a particular work group with a common interest to have an interactive brainstorming debate on a topic of their choice. Consider it to be a panel discussion — except everyone on the call is part of the panel! I coordinated the first webjam for The Cloud Work Group — the topic was “What will Cloud do to your resume?”

The webjam was attended by active members of the Cloud work group including

  • Sanda Morar and Som Balakrishnan from Cognizant Technologies
  • Raj Bhoopathi and E.G.Nadhan from HP.
  • Chris Harding from The Open Group

We used this post on the ECIO Forum Blog to set the context for this webjam. Click here for recording. Below is a brief summary of the key takeaways:

  • Cloud Computing is causing significant shifts that could impact the extent to which some roles exist in the future—especially the role of the CTO and the CIO. The CIO must become a cooperative integrator across a heterogeneous mix of technologies, platforms and services that are provisioned on or off the cloud.
  • Key Cloud characteristics—such as multi-tenancy, elasticity, scalability, etc.—are likely to be called out in resumes. There is an accelerated push for Cloud Architects who are supposed to ensure that aspects of the Cloud are consistently addressed across all architectural layers.
  • DevOps is expanding the role of the developer to transcend into operations. Developers’ resumes are more likely to call this experience out in Cloud Computing environments.
  • Business users are likely to call out their experience directly procuring Cloud services.
  • Application testers are more likely to address interoperability between the services provided—including the validation of the projected service levels—which could, in turn, show up on their resumes.
  • Operations personnel are likely to call out their experience with tools that can seamlessly monitor physical and virtual resources.

The recording provides much more detail.

I really enjoyed the webjam. It provided an opportunity to share the perspectives of individuals from numerous member companies of The Open Group on a topic germane to us as IT professionals as well as to The Cloud Work Group.

Are there other roles that are impacted? Are there any other changes to the content of the resumes in the future? Please listen to the recording and let me know your thoughts.

If you are a member of the Cloud Work Group, I look forward to engaging in an interesting discussion with you on other topics in this area!

A version of this blog post was originally published on HP’s Journey through Enterprise IT Services blog.

NadhanHP Distinguished Technologist and Cloud Advisor, E.G.Nadhan has more than 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project, and is also the founding co-chair for the Open Group Cloud Computing Governance project. Connect with Nadhan on: Twitter, Facebook, LinkedIn and Journey Blog.

 

Comments Off

Filed under Cloud, Cloud/SOA

Flying in the Cloud by the Seat of Our Pants

By Chris Harding, The Open Group

In the early days of aviation, when instruments were unreliable or non-existent, pilots often had to make judgments by instinct. This was known as “flying by the seat of your pants.” It was exciting, but error prone, and accidents were frequent. Today, enterprises are in that position with Cloud Computing.

Staying On Course

Flight navigation does not end with programming the flight plan. The navigator must check throughout the flight that the plane is on course.  Successful use of Cloud requires, not only an understanding of what it can do for the business, but also continuous monitoring that it is delivering value as expected. A change of service-level, for example, can have as much effect on a user enterprise as a change of wind speed on an aircraft.

The Open Group conducted a Cloud Return on Investment (ROI) survey in 2011. Then, 55 percent of those surveyed felt that Cloud ROI would be easy to evaluate and justify, although only 35 percent had mechanisms in place to do it. When we repeated the survey in 2012, we found that the proportion that thought it would be easy had gone down to 44 percent, and only 20 percent had mechanisms in place. This shows, arguably, more realism, but it certainly doesn’t show any increased tendency to monitor the value delivered by Cloud. In fact, it shows the reverse. The enterprise pilots are flying by the seats of their pants. (The full survey results are available at http://www.opengroup.org/sites/default/files/contentimages/Documents/cloud_roi_formal_report_12_19_12-1.pdf)

They Have No Instruments

It is hard to blame the pilots for this, because they really do not have the instruments. The Open Group published a book in 2011, Cloud Computing for Business, that explains how to evaluate and monitor Cloud risk and ROI, with spreadsheet examples. The spreadsheet is pretty much the state-of-the-art in Cloud ROI instrumentation.  Like a compass, it is robust and functional at a basic level, but it does not have the sophistication and accuracy of a satellite navigation system. If we want better navigation, we must have better systems.

There is scope for Enterprise Architecture tool vendors to fill this need. As the inclusion of Cloud in Enterprise Architectures becomes commonplace, and Cloud Computing metrics and their relation to ROI become better understood, it should be possible to develop the financial components of Enterprise Architecture modeling tools so that the business impact of the Cloud systems can be seen more clearly.

The Enterprise Flight Crew

But this is not just down to the architects. The architecture is translated into systems by developers, and the systems are operated by operations staff. All of these people must be involved in the procurement and configuration of Cloud services and their monitoring through the Cloud buyers’ life cycle.

Cloud is already bringing development and operations closer together. The concept of DevOps, a paradigm that stresses communication, collaboration and integration between software developers and IT operations professionals, is increasingly being adopted by enterprises that use Cloud Computing. This communication, collaboration and integration must involve – indeed must start with – enterprise architects, and it must include the establishment and monitoring of Cloud ROI models. All of these professionals must co-operate to ensure that the Cloud-enabled enterprise keeps to its financial course.

The Architect as Pilot

The TOGAF® architecture development method includes a phase (Phase G) in which the architects participate in implementation governance. The following Phase H is currently devoted to architecture change management, with the objectives of ensuring that the architecture lifecycle is maintained, the architecture governance framework is executed, and the Enterprise Architecture capability meets current requirements. Perhaps Cloud architects should also think about ensuring that the system meets its business requirements, and continues to do so throughout its operation. They can then revisit earlier phases of the architecture development cycle (always a possibility in TOGAF) if it does not.

Flying the Cloud

Cloud Computing compresses the development lifecycle, cutting the time to market of new products and the time to operation of new enterprise systems. This is a huge benefit. It implies closer integration of architecture, development and operations. But this must be supported by proper instrumentation of the financial parameters of Cloud services, so that the architecture, development and operations professionals can keep the enterprise on course.

Flying by the seat of the pants must have been a great experience for the magnificent men in the flying machines of days gone by, but no one would think of taking that risk with the lives of 500 passengers on a modern aircraft. The business managers of a modern enterprise should not have to take that risk either. We must develop standard Cloud metrics and ROI models, so that they can have instruments to measure success.

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.

10 Comments

Filed under Cloud/SOA

Data Governance: A Fundamental Aspect of IT

By E.G. Nadhan, HP

In an earlier post, I had explained how you can build upon SOA governance to realize Cloud governance.  But underlying both paradigms is a fundamental aspect that we have been dealing with ever since the dawn of IT—and that’s the data itself.

In fact, IT used to be referred to as “data processing.” Despite the continuing evolution of IT through various platforms, technologies, architectures and tools, at the end of the day IT is still processing data. However, the data has taken multiple shapes and forms—both structured and unstructured. And Cloud Computing has opened up opportunities to process and store structured and unstructured data. There has been a need for data governance since the day data processing was born, and today, it’s taken on a whole new dimension.

“It’s the economy, stupid,” was a campaign slogan, coined to win a critical election in the United States in 1992. Today, the campaign slogan for governance in the land of IT should be, “It’s the data, stupid!”

Let us challenge ourselves with a few questions. Consider them the what, why, when, where, who and how of data governance.

What is data governance? It is the mechanism by which we ensure that the right corporate data is available to the right people, at the right time, in the right format, with the right context, through the right channels.

Why is data governance needed? The Cloud, social networking and user-owned devices (BYOD) have acted as catalysts, triggering an unprecedented growth in recent years. We need to control and understand the data we are dealing with in order to process it effectively and securely.

When should data governance be exercised? Well, when shouldn’t it be? Data governance kicks in at the source, where the data enters the enterprise. It continues across the information lifecycle, as data is processed and consumed to address business needs. And it is also essential when data is archived and/or purged.

Where does data governance apply? It applies to all business units and across all processes. Data governance has a critical role to play at the point of storage—the final checkpoint before it is stored as “golden” in a database. Data Governance also applies across all layers of the architecture:

  • Presentation layer where the data enters the enterprise
  • Business logic layer where the business rules are applied to the data
  • Integration layer where data is routed
  • Storage layer where data finds its home

Who does data governance apply to? It applies to all business leaders, consumers, generators and administrators of data. It is a good idea to identify stewards for the ownership of key data domains. Stewards must ensure that their data domains abide by the enterprise architectural principles.  Stewards should continuously analyze the impact of various business events to their domains.

How is data governance applied? Data governance must be exercised at the enterprise level with federated governance to individual business units and data domains. It should be proactively exercised when a new process, application, repository or interface is introduced.  Existing data is likely to be impacted.  In the absence of effective data governance, data is likely to be duplicated, either by chance or by choice.

In our data universe, “informationalization” yields valuable intelligence that enables effective decision-making and analysis. However, even having the best people, process and technology is not going to yield the desired outcomes if the underlying data is suspect.

How about you? How is the data in your enterprise? What governance measures do you have in place? I would like to know.

A version of this blog post was originally published on HP’s Journey through Enterprise IT Services blog.

NadhanHP Distinguished Technologist and Cloud Advisor, E.G.Nadhan has more than 25 years of experience in the IT industry across the complete spectrum of selling, delivering and managing enterprise level solutions for HP customers. He is the founding co-chair for The Open Group SOCCI project, and is also the founding co-chair for the Open Group Cloud Computing Governance project. Connect with Nadhan on: Twitter, Facebook, LinkedIn and Journey Blog.

1 Comment

Filed under Cloud, Cloud/SOA

2013 Open Group Predictions, Vol. 1

By The Open Group

A big thank you to all of our members and staff who have made 2012 another great year for The Open Group. There were many notable achievements this year, including the release of ArchiMate 2.0, the launch of the Future Airborne Capability Environment (FACE™) Technical Standard and the publication of the SOA Reference Architecture (SOA RA) and the Service-Oriented Cloud Computing Infrastructure Framework (SOCCI).

As we wrap up 2012, we couldn’t help but look towards what is to come in 2013 for The Open Group and the industries we‘re a part of. Without further ado, here they are:

Big Data
By Dave Lounsbury, Chief Technical Officer

Big Data is on top of everyone’s mind these days. Consumerization, mobile smart devices, and expanding retail and sensor networks are generating massive amounts of data on behavior, environment, location, buying patterns – etc. – producing what is being called “Big Data”. In addition, as the use of personal devices and social networks continue to gain popularity so does the expectation to have access to such data and the computational power to use it anytime, anywhere. Organizations will turn to IT to restructure its services so it meets the growing expectation of control and access to data.

Organizations must embrace Big Data to drive their decision-making and to provide the optimal service mix services to customers. Big Data is becoming so big that the big challenge is how to use it to make timely decisions. IT naturally focuses on collecting data so Big Data itself is not an issue.. To allow humans to keep on top of this flood of data, industry will need to move away from programming computers for storing and processing data to teaching computers how to assess large amounts of uncorrelated data and draw inferences from this data on their own. We also need to start thinking about the skills that people need in the IT world to not only handle Big Data, but to make it actionable. Do we need “Data Architects” and if so, what would their role be?

In 2013, we will see the beginning of the Intellectual Computing era. IT will play an essential role in this new era and will need to help enterprises look at uncorrelated data to find the answer.

Security

By Jim Hietala, Vice President of Security

As 2012 comes to a close, some of the big developments in security over the past year include:

  • Continuation of hacktivism attacks.
  • Increase of significant and persistent threats targeting government and large enterprises. The notable U.S. National Strategy for Trusted Identities in Cyberspace started to make progress in the second half of the year in terms of industry and government movement to address fundamental security issues.
  • Security breaches were discovered by third parties, where the organizations affected had no idea that they were breached. Data from the 2012 Verizon report suggests that 92 percent of companies breached were notified by a third party.
  • Acknowledgement from senior U.S. cybersecurity professionals that organizations fall into two groups: those that know they’ve been penetrated, and those that have been penetrated, but don’t yet know it.

In 2013, we’ll no doubt see more of the same on the attack front, plus increased focus on mobile attack vectors. We’ll also see more focus on detective security controls, reflecting greater awareness of the threat and on the reality that many large organizations have already been penetrated, and therefore responding appropriately requires far more attention on detection and incident response.

We’ll also likely see the U.S. move forward with cybersecurity guidance from the executive branch, in the form of a Presidential directive. New national cybersecurity legislation seemed to come close to happening in 2012, and when it failed to become a reality, there were many indications that the administration would make something happen by executive order.

Enterprise Architecture

By Leonard Fehskens, Vice President of Skills and Capabilities

Preparatory to my looking back at 2012 and forward to 2013, I reviewed what I wrote last year about 2011 and 2012.

Probably the most significant thing from my perspective is that so little has changed. In fact, I think in many respects the confusion about what Enterprise Architecture (EA) and Business Architecture are about has gotten worse.

The stress within the EA community as both the demands being placed on it and the diversity of opinion within it increase continues to grow.  This year, I saw a lot more concern about the value proposition for EA, but not a lot of (read “almost no”) convergence on what that value proposition is.

Last year I wrote “As I expected at this time last year, the conventional wisdom about Enterprise Architecture continues to spin its wheels.”  No need to change a word of that. What little progress at the leading edge was made in 2011 seems to have had no effect in 2012. I think this is largely a consequence of the dust thrown in the eyes of the community by the ascendance of the concept of “Business Architecture,” which is still struggling to define itself.  Business Architecture seems to me to have supplanted last year’s infatuation with “enterprise transformation” as the means of compensating for the EA community’s entrenched IT-centric perspective.

I think this trend and the quest for a value proposition are symptomatic of the same thing — the urgent need for Enterprise Architecture to make its case to its stakeholder community, especially to the people who are paying the bills. Something I saw in 2011 that became almost epidemic in 2012 is conflation — the inclusion under the Enterprise Architecture umbrella of nearly anything with the slightest taste of “business” to it. This has had the unfortunate effect of further obscuring the unique contribution of Enterprise Architecture, which is to bring architectural thinking to bear on the design of human enterprise.

So, while I’m not quite mired in the slough of despond, I am discouraged by the community’s inability to advance the state of the art. In a private communication to some colleagues I wrote, “the conventional wisdom on EA is at about the same state of maturity as 14th century cosmology. It is obvious to even the most casual observer that the earth is both flat and the center of the universe. We debate what happens when you fall off the edge of the Earth, and is the flat earth carried on the back of a turtle or an elephant?  Does the walking of the turtle or elephant rotate the crystalline sphere of the heavens, or does the rotation of the sphere require the turtlephant to walk to keep the earth level?  These are obviously the questions we need to answer.”

Cloud

By Chris Harding, Director of Interoperability

2012 has seen the establishment of Cloud Computing as a mainstream resource for enterprise architects and the emergence of Big Data as the latest hot topic, likely to be mainstream for the future. Meanwhile, Service-Oriented Architecture (SOA) has kept its position as an architectural style of choice for delivering distributed solutions, and the move to ever more powerful mobile devices continues. These trends have been reflected in the activities of our Cloud Computing Work Group and in the continuing support by members of our SOA work.

The use of Cloud, Mobile Computing, and Big Data to deliver on-line systems that are available anywhere at any time is setting a new norm for customer expectations. In 2013, we will see the development of Enterprise Architecture practice to ensure the consistent delivery of these systems by IT professionals, and to support the evolution of creative new computing solutions.

IT systems are there to enable the business to operate more effectively. Customers expect constant on-line access through mobile and other devices. Business organizations work better when they focus on their core capabilities, and let external service providers take care of the rest. On-line data is a huge resource, so far largely untapped. Distributed, Cloud-enabled systems, using Big Data, and architected on service-oriented principles, are the best enablers of effective business operations. There will be a convergence of SOA, Mobility, Cloud Computing, and Big Data as they are seen from the overall perspective of the enterprise architect.

Within The Open Group, the SOA and Cloud Work Groups will continue their individual work, and will collaborate with other forums and work groups, and with outside organizations, to foster the convergence of IT disciplines for distributed computing.

3 Comments

Filed under Business Architecture, Cloud, Cloud/SOA, Cybersecurity, Enterprise Architecture

The Center of Excellence: Relating Everything Back to Business Objectives

By Serge Thorn, Architecting the Enterprise

This is the third and final installment of a 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, my second blog post suggested how the Center of Excellence would define a Reference Architecture for the organization.

 SOA principles should clearly relate back to the business objectives and key architecture drivers. They will be constructed on the same mode as TOGAF 9.1 principles with the use of statement, rationale and implications. Below examples of the types of services which may be created:

  • Put the computing near the data
  • Services are technology neutral
  • Services are consumable
  • Services are autonomous
  • Services share a formal contract
  • Services are loosely coupled
  • Services abstract underlying logic
  • Services are reusable
  • Services are composable
  • Services are stateless
  • Services are discoverable
  • Location Transparency

Here is a detailed principle example:

  • Service invocation
    • All service invocations between application silos will be exposed through the Enterprise Service Bus (ESB)
    • The only exception to this principle will be when the service meets all the following criteria:
      • It will be used only within the same application silo
      • There is no potential right now or in the near future for re-use of this service
      • The service has already been right-sized
      • The  Review Team has approved the exception

As previously indicated, the SOA Center of Excellence (CoE) would also have to provide guidelines on SOA processes and related technologies. This may include:

  • Service analysis (Enterprise Architecture, BPM, OO, requirements and models, UDDI Model)
  • Service design (SOAD, specification, Discovery Process, Taxonomy)
  • Service provisioning (SPML, contracts, SLA)
  • Service implementation development (BPEL, SOAIF)
  • Service assembly and integration (JBI, ESB)
  • Service testing
  • Service deployment (the software on the network)
  • Service discovery (UDDI, WSIL, registry)
  • Service publishing (SLA, security, certificates, classification, location, UDDI, etc.)
  • Service consumption (WSDL, BPEL)
  • Service execution  (WSDM)
  • Service versioning (UDDI, WSDL)
  • Service Management and monitoring
  • Service operation
  • Programming, granularity and abstraction

Other activities may be considered by the SOA CoE such as providing a collaboration platform, asset management (service are just another type of assets), compliance with standards and best practices, use of guidelines, etc. These activities could also be supported by an Enterprise Architecture team.

As described in the TOGAF® 9.1 Framework, the SOA CoE can act as the governance body for SOA implementation, work with the Enterprise Architecture team, overseeing what goes into a new architecture that the organization is creating and ensuring that the architecture will meet the current and future needs of the organization.

The Center of Excellence provides expanded opportunities for organizations to leverage and reuse service-oriented infrastructure and knowledgebase to facilitate the implementation of cost-effective and timely SOA based solutions.

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

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

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

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