Friday, February 8, 2013

Three best practices for successful implementation of enterprise architecture using the TOGAF framework and the ArchiMate modeling language


This guest post comes courtesy of The Open Group and BiZZdesign

By Henry Franken, Sven van Dijk and Bas van Gils, BiZZdesign

The discipline of enterprise architecture (EA) was developed in the 1980s with a strong focus on the information systems landscape of organizations. Since those days, the scope of the discipline has slowly widened to include more and more aspects of the enterprise as a whole. This holistic perspective takes into account the concerns of a wide variety of stakeholders. Architects, especially at the strategic level, attempt to answer the question: “How should we organize ourselves in order to be successful?”

An architecture framework is a foundational structure or set of structures for developing a broad range of architectures and consists of a process and a modeling component. The TOGAF framework and the ArchiMate modeling language – both maintained by The Open Group – are two leading and widely adopted standards in this field.

While both the TOGAF framework and the ArchiMate modeling language have a broad (enterprise-wide) scope and provide a practical starting point for an effective EA capability, a key factor is the successful embedding of EA standards and tools in the organization. From this perspective, the implementation of EA means that an organization adopts processes for the development and governance of EA artifacts and deliverables. Standards need to be tailored, and tools need to be configured in the right way in order to create the right fit. Or more popularly stated, “For an effective EA, it has to walk the walk, and talk the talk of the organization.”

EA touches on many aspects such as business, IT (and especially the alignment of these two), strategic portfolio management, project management, and risk management. EA is by definition about cooperation and therefore it is impossible to operate in isolation. Successful embedding of an EA capability in the organization is typically approached as a change project with clearly defined goals, metrics, stakeholders, appropriate governance and accountability, and with assigned responsibilities in place.

With this in mind, we share three best practices for the successful implementation of EA:

Think big, start small

The potential footprint of a mature EA capability is as big as the entire organization, but one of the key success factors for being successful with EA is to deliver value early on. Experience from our consultancy practice proves that a “think big, start small” approach has the most potential for success. This means that the process of implementing an EA capability is a process with iterative and incremental steps, based on a long term vision. Each step in the process must add measurable value to the EA practice, and priorities should be based on the needs and the change capacity of the organization.

Combine process and modeling

The TOGAF framework and the ArchiMate modeling language are a powerful combination. Deliverables in the architecture process are more effective when based on an approach that combines formal models with powerful visualization capabilities.

Franken
The TOGAF standard describes the architecture process in detail. The Architecture Development Method (ADM) is the core of the TOGAF standard. The ADM is a customer-focused and value-driven process for the sustainable development of a business capability. The ADM specifies deliverables throughout the architecture life-cycle with a focus on the effective communication to a variety of stakeholders.

ArchiMate is fully complementary to the content as specified in the TOGAF standard. The ArchiMate standard can be used to describe all aspects of the EA in a coherent way, while tailoring the content for a specific audience. Even more, an architecture repository is a valuable asset that can be reused throughout the enterprise. This greatly benefits communication and cooperation of enterprise architects and their stakeholders.

Use a tool

It is true, “a fool with a tool is still a fool.” In our teaching and consulting practice we have found, however, that adoption of a flexible and easy to use tool can be a strong driver in pushing the EA initiative forward.

van Dijk
EA brings together valuable information that greatly enhances decision making, whether on a strategic or more operational level. This knowledge not only needs to be efficiently managed and maintained, it also needs to be communicated to the right stakeholder at the right time, and even more importantly, in the right format.

EA has a diverse audience that has business and technical backgrounds, and each of the stakeholders needs to be addressed in a language that is understood by all. Therefore, essential qualifications for EA tools are: rigidity when it comes to the management and maintenance of knowledge and flexibility when it comes to the analysis (ad-hoc, what-if, etc.), presentation, and communication of the information to diverse audiences.

So what you are looking for is a tool with solid repository capabilities, flexible modeling and analysis functionality.

Conclusion

EA brings value to the organization because it answers more accurately the question: “How should we organize ourselves?” Standards for EA help monetize on investments in EA more quickly. The TOGAF framework and the ArchiMate modeling language are popular, widespread, open and complete standards for EA, both from a process and a language perspective.

van Gils
EA becomes even more effective if these standards are used in the right way. The EA capability needs to be carefully embedded in the organization. This is usually a process based on a long term vision and has the most potential for success if approached as “think big, start small.” Enterprise Architects can benefit from tool support, provided that it supports flexible presentation of content, so that it can be tailored for the communication to specific audiences.

More information on this subject can be found on our website: www.bizzdesign.com. Whitepapers are available for download, and our blog section features a number of very interesting posts regarding the subjects covered in this paper.

If you would like to know more or comment on this blog, or please do not hesitate to contact us directly.

Henry Franken is the managing director of BiZZdesign and is chair of The Open Group ArchiMate Forum. As chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate Version 2.o standard. Henry is a speaker at many conferences and has co-authored several international publications and Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for research and innovation.

 Sven van Dijk Msc. is a consultant and trainer at BiZZdesign North America. He worked as an application consultant on large scale ERP implementations and as a business consultant in projects on information management and IT strategy in various industries such as finance and construction. He gained nearly eight years of experience in applying structured methods and tools for Business Process Management and Enterprise Architecture.

 Bas van Gils is a consultant, trainer and researcher for BiZZdesign. His primary focus is on strategic use of enterprise architecture. Bas has worked in several countries, across a wide range of organizations in industry, retail, and (semi)governmental settings.  Bas is passionate about his work, has published in various professional and academic journals and writes for several blogs.

This guest post comes courtesy of The Open Group and BiZZdesign
 
Copyright The Open Group, 2013. All rights reserved

You may also be interested in:

at 11:21 AM 0 comments

Tuesday, February 5, 2013

US Department of Energy: Proving the cloud service broker model

This BriefingsDirect guest post comes courtesy of Jason Bloomberg, president of ZapThink, a Dovel Technologies company.

By Jason Bloomberg

Emerging markets don’t generally follow smooth, predictable paths. Rather, they struggle and jerk unexpectedly, much like an eaglet escaping from its shell. Vendors, analysts, and pundits may seek to define such markets, but typically fall short. After all, vendors don’t establish markets. Customers do.

Today, cloud computing is still in its birth throes. Yes, many organizations are now achieving value in the cloud, but many more still struggle to understand its true value proposition as cloud service providers (CSPs) and vendors mature their offerings in the space. One problem: cloud computing is not a single market. It is in fact many interrelated markets, as its core service models, infrastructure-, platform-, and software as a service (SaaS), fragment as though they were so many pieces of eggshell.

Bloomberg
To bring order to this chaos, a new sub-market of the broader cloud-computing market has emerged: the cloud service broker (CSB). Envision some kind of cloud middleman, helping to cut through the plethora of cloud options and services by offering…well, just what a CSB offers isn’t quite clear. And that’s the problem with the whole notion of a CSB. The market has yet to fully define it.

Not that there aren’t plenty of perspectives on just what a CSB should actually do, mind you. If anything, there are too many opinions, prompting arguments among bloggers and confusion among customers.

Gartner claims CSBs should offer aggregation, integration, and customization, while Forrester delineates simple cloud brokers, full infrastructure brokers, and SaaS brokers – at least initially. And then there’s the National Institute for Standards and Technology (NIST), who calls for CSBs to provide aggregation, intermediation, and arbitrage, specifically for brokers that would serve the US federal government.
There’s only one way to cut through this confusion: talk to an organization who not only figured out what they wanted from a CSB, but also built one themselves.

But poke around the blogosphere, and many other CSB features come to light. Management is a huge requirement -- or two requirements, actually, as some organizations have needs that focus on business management, while others focus more on the technical aspects of management.

And what about assessments? Shouldn’t your broker assess CSPs who wish to join the CSB, providing some kind of thumbs-up before providers can participate? Then there are the questions about the nature and configuration of the CSB itself. Is it internal to the organization, or a third party much like a real-estate broker might be? And finally, is the broker essentially a software solution, or is it an organization or team in its own right, where software plays a support role to what are essentially a set of brokering business processes?

There’s only one way to cut through this confusion: talk to an organization who not only figured out what they wanted from a CSB, but also built one themselves. The organization in question: the National Nuclear Security Administration (NNSA), an agency of the United States Department of Energy (DOE).

Management and security

According to its Web site, NNSA is responsible for the management and security of the nation’s nuclear weapons, nuclear nonproliferation, naval reactor programs, and related activities. Under the auspices of Deputy Chief Technology Officer Anil Karmel, NNSA and the Los Alamos National Lab (LANL) implemented a CSB they call YOURcloud, in collaboration with partners in the contractor community.

According to Karmel, YOURcloud both leverages and supports the DOE’s Information on Demand (IoD) strategy. It provides a self-service portal for infrastructure-as-a-service (IaaS) offerings across multiple CSPs, including on-premise, community, and public cloud services like Amazon’s Elastic Compute Cloud (EC2). YOURcloud balances a diversity of choices among IaaS providers for various DOE programs while allowing those programs to maintain full autonomy of their cloud workloads.

YOURcloud users include DOE users, laboratory and plant users, other government agency users, support contractors, and members of the public. DOE business use cases for the CSB include rapid deployment of servers to scientists, security controls based on data sensitivity, calculating energy savings, disaster recovery, and capital expenditure reduction. And of course, security is a paramount concern.

Karmel describes YOURcloud as a “Cloud of Clouds.” In other words, it’s a secure hybrid CSB that incorporates both on-premise and public cloud offerings. This approach gives them a unified management control plane for IaaS and IoD, and in fact, this technical management capability is central to the role of the CSB at NNSA.
The central problem that led NNSA to build YOURcloud was their desire to deploy cloud services rapidly.

The central problem that led NNSA to build YOURcloud was their desire to deploy cloud services rapidly. Before the debut of the broker, cloud deployments had taken 70 days or more, according to Karmel.

NNSA also required a comprehensive security plan that was more sophisticated than the security capabilities other CSBs, both in production as well as on the drawing board, might offer. To this end, YOURcloud delivers software-defined security covering network, storage, and compute resources. It provides adaptive security that covers both NNSA’s virtual desktop infrastructure (VDI) as well as service enclaves.

In fact, the notion of service enclaves is central to how YOURcloud deals with security. It’s possible to partition enclaves so that an organization can use one cloud, while protecting sensitive data from users who lack the credentials to access the information in that cloud.

In essence, enclaves provide a container for both workloads and configurations. After a program creates an enclave, it establishes role-based access control (RBAC) by assigning permissions to the organization’s technical staff. In the future, YOURcloud will also provide a shared services enclave that will provide the foundation for enterprise “app store” functionality for the DOE broadly and NNSA in particular.

Critical function

 Organization-centric user registration is also a critical function of the CSB. NNSA requires that YOURcloud identify each participating organizations’ top-level contacts in part to prevent unnecessary organization overlap. Users include technical contacts who select providers, create enclaves, grant permissions, and manage configurations. In particular, security contacts provide organizational firewall control, while billing contacts handle billing statement controls.

Cost reduction is one of the most trumpeted benefits of cloud computing, but the government procurement context complicates the ability of departments to leverage the cloud’s utility model. It’s essential, therefore, for YOURcloud to define the cost structure for IaaS, including the duration of the infrastructure services as well as the mechanism for payment.

Simple pay-as-you-go pricing, however, won’t work for the DOE. The risk with such pricing, of course, is the possibility of an unexpectedly large bill. Such unpredictability is inconsistent with normal government procurement processes. Instead, agencies require full allocation, meaning a fixed price for a maximum level of consumption of cloud services. YOURcloud facilitates this full allocation pricing model, and also enables programs to turn off cloud services and hold them for future use. In effect, delivery of the CSB enables the DOE to save money while simultaneously providing an agnostic platform for innovation.

Since NNSA is a government agency, it’s no surprise that YOURcloud follows NIST’s definition of a CSB more closely than Gartner’s or Forrester’s. In fact, YOURcloud exhibits all three of NIST’s CSB capabilities: aggregation, intermediation, and arbitrage. Not only does YOURcloud aggregate pre-approved CSPs, it provides both business intermediation as well technical intermediation.
Perhaps the most important asset YOURcloud brings to the table for DOE is how well it supports program autonomy.

The current version of YOURcloud also has limited arbitrage capabilities in the form of a dynamic cost calculator, as well as chargeback and showback functionality (showback refers to providing management with an analysis of the IT costs due to each department, without actually charging those costs back to the departments).

Perhaps the most important asset YOURcloud brings to the table for DOE is how well it supports program autonomy. YOURcloud allows programs within the DOE to maintain full control over their workloads within the context of a common security baseline. Karmel’s cloud-of-clouds approach enables YOURcloud to broker any organization, through any device, to any service. This respect for program autonomy addresses the “not invented here” problem: program managers can leverage the capabilities of YOURcloud without feeling like the broker is pushing them to select services or follow policies that are not in line with their requirements.

It’s not clear how well YOURcloud will define the characteristics of CSBs across the entire cloud-computing market, but NNSA’s efforts have not gone without notice within the federal government. CSBs are a hot topic across both civilian and military agencies, with the General Services Administration (GSA) and the Defense Information Systems Agency (DISA) both fleshing out their respective CSB strategies.

That being said, there is no better way to prove a model than by implementing a working, successful example. By implementing a CSB that supports secure, hybrid Cloud environments, NNSA and the DOE have set the bar for the next generation of Cloud Service Brokers.

This BriefingsDirect guest post comes courtesy of Jason Bloomberg, president of ZapThink, a Dovel Technologies company.

You may also be interested in:


at 1:53 PM 0 comments
Subscribe to: Posts (Atom)