Tag Archives: TOGAF

5 Tips Enterprise Architects Can Learn from the Winchester Mystery House

By E.G.Nadhan, HP Enterprise Services

Not far from where The Open Group Conference was held in San Francisco this week is the Winchester Mystery House, once the personal residence of Sarah Winchester, widow of the gun magnate William Wirt Winchester. It took 38 years to build this house. Extensions and modifications were primarily based on a localized requirement du jour. Today, the house has several functional abnormalities that have no practical explanation.

To build a house right, you need a blueprint that details what is to be built, where, why and how based on the home owner’s requirements (including cost). As the story goes, Sarah Winchester’s priorities were different. However, if we don’t follow this systematic approach as enterprise architects, we are likely to land up with some Winchester IT houses as well.

Or, have we already? Enterprises are always tempted to address the immediate problem at hand with surprisingly short timelines. Frequent implementations of sporadic, tactical additions evolve to a Winchester Architecture. Right or wrong, Sarah Winchester did this by choice. If enterprises of today land up with such architectures, it can only by chance and not by choice.

So, here are my tips to architect by choice rather than chance:

  • Establish your principles: Fundamental architectural principles must be in place that serve as a rock solid foundation upon which architectures are based. These principles are based on generic, common-sense tenets that are refined to apply specifically to your enterprise.
  • Install solid governance: The appropriate level of architectural governance must be in place with the participation from the stakeholders concerned. This governance must be exercised, keeping these architectural principles in context.
  • Ensure business alignment: After establishing the architectural vision, Enterprise Architecture must lead in with a clear definition of the over-arching business architecture which defines the manner in which the other architectural layers are realized. Aligning business to IT is one of the primary responsibilities of an enterprise architect.
  • Plan for continuous evaluation: Enterprise Architecture is never really done. There are constant triggers (internal and external) for implementing improvements and extensions. Consumer behavior, market trends and technological evolution can trigger aftershocks within the foundational concepts that the architecture is based upon.

Thus, it is interesting that The Open Group conference was miles away from the Winchester House. By choice, I would expect enterprise architects to go to The Open Group Conference. By chance, if you do happen by the Winchester House and are able to relate it to your Enterprise Architecture, please follow the tips above to architect by choice, and not by chance.

If you have instances where you have seen the Winchester pattern, do let me know by commenting here or following me on Twitter @NadhanAtHP.

This blog post was originally posted on HP’s Transforming IT Blog.

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

4 Comments

Filed under Enterprise Architecture, TOGAF®

What’s New in ArchiMate 2.0?

By Andrew Josey, The Open Group, Henry Franken, BiZZdesign

ArchiMate® 2.0, an Open Group Standard, is an upwards-compatible evolution from ArchiMate 1.0 adding new features, as well as addressing usage feedback and comments raised.

ArchiMate 2.0 standard supports modeling throughout the TOGAF Architecture Development Method (ADM).

Figure 1: Correspondence between ArchiMate and the TOGAF ADM

ArchiMate 2.0 consists of:

  • The ArchiMate Core, which contains several minor improvements on the 1.0 version.
  • The Motivation extension, to model stakeholders, drivers for change, business goals, principles, and requirements. This extension mainly addresses the needs in the early TOGAF phases and the requirements management process.
  • The Implementation and Migration extension, to support project portfolio management, gap analysis, and transition and migration planning. This extension mainly addresses the needs in the later phases of the TOGAF ADM cycle.

ArchiMate 2.0 offers a modeling language to create fully integrated models of the organization’s enterprise architecture, the motivation for the enterprise architecture, and the programs, projects and migration paths to implement this enterprise architecture. In this way, full (forward and backward) traceability between the elements in the enterprise architecture, their motivations and their implementation can be obtained.

In the ArchiMate Core, a large number of minor improvements have been made compared to ArchiMate 1.0: inconsistencies have been removed, examples have been improved and additional text has been inserted to clarify certain aspects. Two new concepts have been added based on needs experienced by practitioners:

  • Location: To model a conceptual point or extent in space that can be assigned to structural elements and, indirectly, of behavior elements.
  • Infrastructure Function: To model the internal behavior of a node in the technology layer. This makes the technology layer more consistent with the other two layers.

The Motivation extension defines the following concepts:

  • Stakeholder: The role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.
  • Driver: Something that creates, motivates, and fuels the change in an organization.
  • Assessment: The outcome of some analysis of some driver.
  • Goal: An end state that a stakeholder intends to achieve.
  • Requirement: A statement of need that must be realized by a system.
  • Constraint: A restriction on the way in which a system is realized.
  • Principle: A normative property of all systems in a given context or the way in which they are realized.

For motivation elements, a limited set of relationships has been defined, partly re-used from the ArchiMate Core: aggregation (decomposition), realization, and (positive or negative) influence.

The Implementation and Migration extension defines the following concepts (and re-uses the relationships of the Core):

  • Work Package: A series of actions designed to accomplish a unique goal within a specified time.
  • Deliverable: A precisely defined outcome of a work package.
  • Plateau: A relatively stable state of the architecture that exists during a limited period of time.
  • Gap: An outcome of a gap analysis between two plateaus.

ArchiMate 2 Certification

New with ArchiMate 2.0 is the introduction of a certification program. This includes certification for people and accreditation for training courses. It also includes certification for tools supporting the ArchiMate standard.

The ArchiMate 2 Certification for People program enables professionals around the globe to demonstrate their knowledge of the ArchiMate standard. ArchiMate 2 Certification for People is achieved through an examination and practical exercises as part of an Accredited ArchiMate 2 Training Course.

The Open Group Accreditation for ArchiMate training courses provides an authoritative and independent assurance of the quality and relevance of the training courses.

The Open Group ArchiMate Tool Certification Program makes certification available to tools supporting ArchiMate. The goal of the program is to ensure that architecture artifacts created with a certified tool are conformant to the language.

Further Reading

ArchiMate 2.0 is available for online reading and download from The Open Group Bookstore at www.opengroup.org/bookstore/catalog/c118.htm.

A white paper with further details on ArchiMate 2.0 is available to download from The Open Group Bookstore at www.opengroup.org/bookstore/catalog/w121.htm .

Andrew Josey is Director of Standards within The Open Group. He is currently managing the standards process for The Open Group, and has recently led the standards development projects for TOGAF 9.1, ArchiMate 2.0, IEEE Std 1003.1-2008 (POSIX), and the core specifications of the Single UNIX Specification, Version 4. Previously, he has led the development and operation of many of The Open Group certification development projects, including industry-wide certification programs for the UNIX system, the Linux Standard Base, TOGAF, and IEEE POSIX. He is a member of the IEEE, USENIX, UKUUG, and the Association of Enterprise Architects.

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.

Comments Off

Filed under Enterprise Architecture, TOGAF®, ArchiMate®, Standards, TOGAF, Business Architecture

Security and Cloud Computing Themes to be explored at The Open Group San Francisco Conference

By The Open Group Conference Team

Cybersecurity and Cloud Computing are two of the most pressing trends facing enterprises today. The Open Group Conference San Francisco will feature tracks on both trends where attendees can learn about the latest developments in both disciplines as well as hear practical advice for implementing both secure architectures and for moving enterprises into the Cloud.  Below are some of the highlights and featured speakers from both tracks.

Security

The San Francisco conference will provide an opportunity for practitioners to explore the theme of “hacktivism,” the use and abuse of IT to drive social change, and its potential impact on business strategy and Enterprise Transformation.  Traditionally, IT security has focused on protecting the IT infrastructure and the integrity of the data held within.  However, in a rapidly changing world where hacktivism is an enterprise’s biggest threat, how can enterprise IT security respond?

Featured speakers and panels include:

  • Steve Whitlock, Chief Security Strategist, Boeing, “Information Security in the Internet Age”
  • Jim Hietala, Vice President, Security, The Open Group, “The Open Group Security Survey Results”
  • Dave Hornford, Conexiam, and Chair, The Open Group Architecture Forum, “Overview of TOGAF® and SABSA® Integration White Paper”
  • Panel – “The Global Supply Chain: Presentation and Discussion on the Challenges of Protecting Products Against Counterfeit and Tampering”

Cloud Computing

According to Gartner, Cloud Computing is now entering the “trough of disillusionment” on its hype cycle. It is critical that organizations better understand the practical business, operational and regulatory issues associated with the implementation of Cloud Computing in order to truly maximize its potential benefits.

Featured speakers and panels include:

  • David JW Gilmour, Metaplexity Associates, “Architecting for Information Security in a Cloud Environment”
  • Chris Lockhart, Senior Enterprise Architect, UnitedHeal, “Un-Architecture: How a Fortune 25 Company Solved the Greatest IT Problem”
  • Penelope Gordon, Cloud and Business Architect, 1Plug Corporation, “Measuring the Business Performance of Cloud Products”
  • Jitendra Maan, Tata Consultancy, “Mobile Intelligence with Cloud Strategy”
  • Panel – “The Benefits, Challenges and Survey of Cloud Computing Interoperability and Portability”
    • Mark Skilton, Capgemini; Kapil Bakshi, Cisco; Jeffrey Raugh, Hewlett-Packard

Please join us in San Francisco for these speaking tracks, as well as those on our featured them of Enterprise Transformation and the role of enterprise architecture. For more information, please go to the conference homepage: http://www3.opengroup.org/sanfrancisco2012

2 Comments

Filed under Cloud, Cloud/SOA, Cybersecurity, Information security, Security Architecture, Semantic Interoperability, TOGAF

How to manage requirements within the Enterprise Architecture using the TOGAF® and SABSA® frameworks

By Pascal de Koning, KPN 

You want to put your company’s business strategy into action. What’s the best way to accomplish this?  This can be done in a structured manner by using an Enterprise Architecture
Framework like TOGAF®. TOGAF® offers an overview of business and IT related architectures, as well as a process model to deliver these, called the Architecture Development Method (ADM-figure 1).

As the figure shows, Requirements Management plays a central role in the architecture work in the TOGAF® methodology. It’s very important to know the business requirements, because these demand what’s needed in the underlying architecture layer. In fact, this counts for every layer. Each architecture layer fulfills the requirements that are defined in the layer above. Without proper Requirements Management, the whole architecture would be loose sand.

Unfortunately, TOGAF® does not offer guidance on Requirements Management. It does however stress the importance and central role of Requirements Management, but doesn’t offer a way to actually do Requirements Management. This is a white spot in the TOGAF® ADM. To resolve this, a requirements management method is needed that is well-described and flexible to use on all levels in the architecture. We found this in the SABSA® (Sherwood’s Applied Business-driven Security Architecture) framework. SABSA® offers the unique Business Attribute Profiling (BAP) technique as a means to effectively carry out Requirements Management.

Business Attribute Profiling is a requirements engineering technique that translates business goals and drivers into requirements (see figure 2). Some advantages of this technique are:

  • Executive communication in non-ICT terms
  • Grouping and structuring of requirements, keeping oversight
  • Traceability mapping between business drivers, requirements and capabilities

The BAP process decomposes the business goal into its core elements. Each core element is a single business attribute. Examples of business attributes are Available, Scalable, Supported, Confidential, Traceable, etc.

As business processes tend to become more Internet-based, cyber security is becoming more important every day because the business processes are increasingly vulnerable to forces outside the business. Organizations must now consider not only the processes and requirements when planning an architecture, but they also need to consider the security of that architecture. A Security Architecture consists of all the security-related drivers, requirements, services and capabilities within the Enterprise. With the adoption of the Business Attribute Profiling technique for Requirements Management, it is now possible to integrate information security into the Enterprise Architecture.

The TOGAF®-SABSA® Integration white paper elaborates more on this and provides a guide that describes how TOGAF® and SABSA® can be combined such that the SABSA® business risk-driven security architecture approach is seamlessly integrated into the a TOGAF®-based enterprise architecture. It can be downloaded from https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?publicationid=12449

TOGAF® is a registered trademark of The Open Group.  SABSA® is a registered trademark of The SABSA Institute.

Pascal de Koning MSc CISSP is a Senior Business Consultant with KPN Trusted Services, where he leads the security consulting practice. He is chairman of The Open Group TOGAF-SABSA Integration Working Group. He has worked on information security projects for the Dutch central government, European Union and KPN, to name just a few. Pascal has written articles for Computable and PvIB, and is a frequent speaker at conferences like RSA Europe and COSAC on the topics of Cyber Security and Enterprise Security Architecture. When not working, Pascal loves to go running.

1 Comment

Filed under Enterprise Architecture, Security Architecture, TOGAF®

Why do pencils have erasers?

By Andrew Josey and Garry Doherty, The Open Group

We know that TOGAF® isn’t perfect. In fact, it probably never will be, but sometimes, especially after a major release, it’s a good idea to stop and look backwards after its been in implementation for a while… just to make sure we’ve gotten it right and to review the standard for reasons of further clarification and to improve consistency.

That’s why we’re releasing TOGAF® 9.1. It contains a set of corrections to address comments raised since the introduction of TOGAF® 9 in 2009. We have been able to address over 400 of the comments received against TOGAF® 9, resulting in over 450 changes to the standard.

The maintenance updates in TOGAF® 9.1 are based on feedback received on the framework as organizations have put it to good use over the past three years. As such the changes are upwards compatible adding clarification, consistency and additional detail where needed. Some of the most significant updates include:

  • The SOA chapter (Part III, Chapter 22, Using TOGAF to Define & Govern SOAs) has been updated to include the latest Open Group SOA Work Group output providing guidance on adapting the ADM phases for SOA
  • ADM Phases E and F (Part II, Chapters 13 and 14) have been reworked to match the level of detail in other phases, and the uses of terminology for Transition Architecture, Roadmap, and Implementation Strategy clarified and made consistent
  • Corrections have been applied to aspects of the Content Metamodel (Part IV, Chapter 34, The Content Metamodel) including the metamodel diagrams
  • The concepts of levels, iterations and partitions have been clarified and made consistent. This includes a reorganization of material in Part III, Chapter 19, Applying Iteration to the ADM and Chapter 20, Applying the ADM across the Architecture Landscape, and also Part V, Chapter 40, Architecture Partitioning
  • The terms “artifact” versus “viewpoint” have been clarified and made consistent. This includes a restructuring of Part IV, Chapter 35, Architectural Artifacts
  • Changes have been made to improve general usability including:
    • The artifacts for each phase are now listed in the phase descriptions
    • Duplicate text in several places has been replaced with an appropriate reference
    • The “Objectives” sections of the phases have been reworked
    • Some artifacts have been renamed to better reflect their usage

If you’re already TOGAF® 9 certified,  don’t worry about the status of your certification. The TOGAF® 9 Certification for People Program has been designed to accommodate maintenance updates to the TOGAF® 9 standard such as TOGAF® 9.1. So impacts on the program are minimal:

  • The two levels of certification remain as TOGAF® 9 Foundation and TOGAF® 9 Certified.
  • Individuals who are currently certified in the TOGAF® 9 People Certification program remain certified.

TOGAF 9.1 is available for online reading at http://www.opengroup.org/togaf/ and available in The Open Group Bookstore at http://www.opengroup.org/bookstore/catalog/g116.htm .

A detailed description of the changes between TOGAF 9 and TOGAF 9.1 is available at http://www.opengroup.org/bookstore/catalog/u112.htm .

So now you know why pencils have erasers… because perfection is a constantly moving target!

5 Comments

Filed under Enterprise Architecture, Standards, TOGAF, TOGAF®

The Open Group and SABSA Institute Publish TOGAF® Integration Whitepaper

By Jim Hietala, Vice President, Security, The Open Group

2011 confirmed what many in the Enterprise Architecture industry have feared – data breaches are on the rise. It’s not just the number and cost of data breaches, but the sheer volume of information that cyber criminals are able to get their hands on. Today’s organizations cannot risk being vulnerable.

To help address this issue, The Open Group Security and Architecture Forums, and the SABSA® Institute, developers of the SABSA® security and risk management framework, joined forces to explore how security methodologies and risk management approaches can be an integrated with enterprise-level architectures for better protection and flexibility.

If you are an enterprise architect with responsibility for ensuring architectures are secure or a security professional tasked with developing secure architectures you’ll be interested in the work the Architecture Forum and SABSA® have done over the last 15 months, culminating in a whitepaper released today that provides a valuable contribution to the security and enterprise architecture communities.

 A Project Designed to Protect

All too often vulnerabilities can occur due to lack of alignment across organizations, with security and IT experts failing to consider the entire infrastructure together rather than different parts separately.

The impetus for this project came from large enterprises and consulting organizations that frequently saw TOGAF® being used as a tool for developing enterprise architecture, and SABSA® as a tool for creating security architectures. Practitioners of either TOGAF® or SABSA® asked for guidance on how best to align these frameworks in practical usage, and on how to re-use artifacts from each.

This quote from the whitepaper sums up the rationale for the effort best:

 “For too long, information security has been considered a separate discipline, isolated from the enterprise architecture. This Whitepaper documents an approach to enhance the TOGAF® enterprise architecture methodology with the SABSA® security architecture approach and thus create one holistic architecture methodology.”

The vision for the project has been to support enterprise architects who need to take operational risk management into account, by providing guidance describing how TOGAF® and SABSA® can be combined such that the SABSA® business risk and opportunity-driven security architecture approach can be seamlessly integrated into the TOGAF® business strategy-driven approach to develop a richer, more complete enterprise architecture.

There are two important focal points for this effort, first to provide a practical approach for seamlessly integrating SABSA® security requirements and services in common TOGAF®-based architecture engagements – instead of treating security as a separate entity within the architecture.

The second focal point is to illustrate how the requirements management processes in TOGAF® can be fulfilled in their widest generic sense (i.e., not only with regard to security architecture) by application of the SABSA® concept of Business Attribute Profiling to the entire ADM process.

Download a free copy of the TOGAF® and SABSA® whitepaper here.

If you are interested in exploring TOGAF® 9, online access to the framework is available here.

Information on SABSA® may be obtained here.

A large number of individuals participated in the development of this valuable resource. Thank you to all project team members who made this effort a reality, including from the SABSA® Institute, the Open Group Architecture Forum, and the Open Group Security Forum!

3 Comments

Filed under Enterprise Architecture, Security Architecture, TOGAF®

What is Business Technology Management and how does it relate to Enterprise Architecture?

By Serge Thorn, Architecting the Enterprise

Business Technology Management (BTM) is not a methodology but I would say a concept, or eventually the aggregation of several guidelines and techniques. It is also described as a management science which aims to unify business and technology business strategies with the aim of extracting the full potential value of business technology solutions. In a nutshell, it allows you to unify business and technology decision making. Sound familiar?

Continue reading

2 Comments

Filed under Enterprise Architecture, TOGAF®

How EA is leading enterprise transformation in France

By Eric Boulay, The Open Group France

Earlier this week, in Paris, The Open Group France held the latest in a series of one-day conferences focused on Enterprise Architecture. As usual, the event delivered high-value content in the form of an excellent keynote presentation and case studies. These covered the retail, gambling, and financial industries — including two from CIOs of major French corporations: Continue reading

2 Comments

Filed under Enterprise Architecture, TOGAF®

Are Business Process Management and Business Architecture a perfect match?

by Serge Thorn, Architecting the Enterprise

Whenever I suggest collaboration between these two worlds, I always observe some sort of astonishment from my interlocutors. Many Enterprise Architects or Business Architects do not realise there may be synergies. Business Process Management (BPM) team have not understood what Enterprise Architecture is all about and the other way around… There is no a single definition of Business Process Management, often it means different things to different people. To keep it very generic, BPM relates to any activities an organization does to support its process efforts.

There are many activities which can be included in such efforts:

  • The use of industry Business Reference Model (or Business Process Reference Model), a reference for the operational activities of an organization, a framework facilitating a functional Lines of Business, such as
      • The Federal Enterprise Architecture Business Reference Model of the US Federal Government
      • The DoD Business Reference Model
      • The Open Group Exploration and Mining Business Reference Model
      • Frameworx (eTOM) for Telco companies
      • The Supply Chain Operations Reference (SCOR®) model
      • The SAP R/3 Reference Model
      • The Oracle Business Models : Oracle Industry Reference Model for Banking, (IRM), Oracle Retail Reference Model
      • And others…
  • The use of organization specific Business Reference models
  • The use of Business process improvement methodologies
      • Lean, a quantitative data driven methodology based on statistics, process understanding and process control
      • Six Sigma, a methodology that mainly focuses on eliminating bad products or services to clients by using statistical evaluation
  • Business Process Reengineering, which in reality is a facet of BPM
  • The understanding of Business Change Management, the process that empowers staff to accept changes that will improve performance and productivity
  • The understanding of Business Transformation, the continuous process, essential to any organization in implementing its business strategy and achieving its vision
  • The use of Business Rules Management which enables organizations to manage business rules for decision automation
  • The understanding of Business Process Outsourcing (BPO) services to reduce costs and increase efficiency
  • The support of Business Process modeling and design, which is illustrated description of business processes, usually created with flow diagrams. The model contains the relationship between activities, processes, sub-processes and information, as well as roles, the organization and resources. This can done with many notations such as flow chart, functional flow block diagram, control flow diagram, Gantt chart, PERT diagram, IDEF, and nowadays with the standard de facto notations such as UML and BPMN
  • The support of BPM tools and suites implementation. With the right, process models can be simulated, to drive workflow or BPMS systems, and can be used as the basis for an automated process monitoring system (BAM)
  • The support of Business Activity Monitoring (BAM), the ability to have end-to-end visibility and control over all parts of a process or transaction that spans multiple applications and people in one or even more companies

To combine Business Process Management and Enterprise Architecture for better business outcomes is definitely the way forward, where BPM provides the business context, understanding, and- metrics, and Enterprise Architecture provides the discipline to translate business vision and strategy into architectural changes. Both are needed for sustainable continuous improvement. When referring to Enterprise Architecture, we would mainly refer to Business Architecture. Business Architecture involves more than just the structure of business processes. It also entails the organization of departments, roles, documents, assets, and all other process-related information.

Business Architects may be defining and implementing the Business Process framework and, in parallel, influencing the strategic direction for Business Process Management and improvement methodologies (e.g. Lean, Six Sigma). The business process owners and Business Analysts are working within their guidelines at multiple levels throughout the organizations’ business process. They have roles and responsibilities to manage, monitor and control their processes.

An important tool in developing Business Architecture is a Business Reference Model. These types of models are enormously beneficial. They can be developed in the organization to build and extend the information architecture. The shared vocabulary (verbal and visual) that emerges from these efforts promotes clear and effective communication.

To illustrate the touch points between Enterprise Architecture and Business Process Management, I have illustrated in the table below the synergies between the two approaches using TOGAF® 9.

In this table, we observe that, there is a perfect match between Business Process Management and the use of an Enterprise Architecture framework such as TOGAF. BPM is often project based and the Business Architect (or Enterprise Architect) may be responsible for identifying cross-project and cross-process capabilities. It can be considered as being the backbone of an Enterprise Architecture program. We can also add to this, that Service Oriented Architecture is the core operational or transactional capability while BPM does the coordination and integration into business processes.

When using BPM tools and suites, you should also consider the following functionalities: workflow, enterprise application integration, content management and business activity monitoring. These four components are traditionally provided by vendors as separate applications which are merged through BPM into a single application with high levels of integration. The implementation of a BPM solution should theoretically eliminate the maintenance and support cost of these four applications resulting in reducing the total cost of ownership.

Business Architecture provides the governance, alignment and transformational context for BPM across business units and silos. Enterprise Architects, Business Architects, Business Analysts should work together with BPM teams, when approaching the topic of Business Process Management. BPM efforts need structures and appropriate methodologies. It needs a structure to guide efforts at different levels of abstraction (separating “the what“ (the hierarchical structure of business functions) from “the how” (how the desired results are achieved), a documented approach and structure to navigate among the business processes of the organization, i.e. a Business Architecture. They also need a methodology such as an Enterprise Architecture framework to retain and leverage what they have learned about managing and conducting BPM projects.

Editor’s note: The Open Group Architecture Forum and the TM Forum have published a technical report exploring the synergies and identifying integration points between TOGAF and Frameworx. Download it here

This article has previously appeared in Serge Thorn’s personal blog and appears here with his permission.

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 has more than 20 years of experience in Banking and Finance and 5 years of experience in the Pharmaceuticals industry. Among various roles, he has been responsible for the Architecture team in an international bank, where he gained wide experience in the deployment and management of information systems in Private Banking, Wealth Management, and also in IT architecture domains such as the Internet, dealing rooms, inter-banking networks, and Middle and Back-office. He then took charge of IT Research and Innovation (a function which consisted of motivating, encouraging creativity, and innovation in the IT Units), with a mission to help to deploy a TOGAF based Enterprise Architecture, taking into account the company IT Governance Framework. He also chaired the Enterprise Architecture Governance worldwide program, integrating the IT Innovation initiative in order to identify new business capabilities that were creating and sustaining competitive advantage for his organization. Serge has been a regular speaker at various conferences, including those by The Open Group. His topics have included, “IT Service Management and Enterprise Architecture”, “IT Governance”, “SOA and Service Management”, and “Innovation”. Serge has also written several articles and whitepapers for different magazines (Pharma Asia, Open Source Magazine). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

3 Comments

Filed under Enterprise Architecture, TOGAF®

Finding the value in SOA

by Stephen Bennett, Oracle

Republished with permission from CIO Update from an article published on behalf of The Open Group.

Confronted with the age old problems of agility and complexity, today’s CIOs are under more pressure than ever to improve the strategic value of IT to the business. At best, these challenges have increased costs, limited innovation and increased risk. At worst, they have reduced IT’s ability to respond to changing business needs in a timely fashion.

Yet, changes for business and IT are continuing to occur at an ever-increasing pace. To keep up, enterprises need to adopt an agile, flexible architecture style with a proven strategic approach to delivering IT to the business.

Over the last year, I have seen a resurgence of CIOs using Enterprise Architecture (EA) as a key tool to address these challenges. In the past, EA has experienced difficulties within the enterprise. It has been unfairly seen as primarily a documentation exercise and, when applied incorrectly, EA can — ironically — become a silo in of itself. To make sure that EA has better success this time, CIOs must make their EA efforts more actionable.

Step back: SOA

Service oriented architecture (SOA) has been positioned as an architectural style specifically intended to reduce costs, increase agility and, most importantly, simplify the business and the interoperation of different parts of that business.

A key principle of SOA is the structuring of business capabilities into meaningful, granular services as opposed to opaque and siloed business functions. This makes it possible to quickly identify and reuse any existing realized functional capabilities, thus avoiding the duplication of similar capabilities across the organization. By standardizing the behavior and interoperation of these services, it’s possible to limit the impacts of change and to forecast the likely chain of impacts.

Despite its popularity, relatively few enterprises have been able to measure and demonstrate the value of SOA. This is due primarily to the approach that enterprises have taken when adopting and applying SOA. In most cases, enterprises interpret SOA as simply another solution development approach. As a result, SOA has been relegated or wrongly positioned as a purely integration technology, rather than the strategic enabler that it can be.

Because of this, SOA must not be seen as a solution development approach that starts and ends once a solution is delivered. It must be seen as an on-going process that, when coupled with a strategic framework, can change and evolve with the business over time. Unfortunately, many enterprises adopt SOA without utilizing a strategic framework, causing a host of challenges for their business.

Just a few of the challenges I have seen include:

  • More complexity and moving parts
  • Increased costs
  • Projects taking longer than before
  • Solutions more fragile than ever
  • Little or no agility
  • Difficulty identifying and discovering services
  • Exponentially growing governance challenges
  • Limited service re-use
  • Duplication of effort leading to service sprawl
  • Multiple siloed technology focused SOAs
  • Funding for service oriented projects being cut

It’s no wonder that SOA has a bad reputation.

To address these challenges, enterprises utilizing or considering adopting SOA must align it with an EA framework that elevates the importance of the needs of the enterprise rather than only considering the requirements of individual projects.

Step forward: TOGAF® 9

Now used by 80 percent of the Fortune Global 50, TOGAF® , an Open Group standard, is an architecture framework that contains a detailed method and set of supporting resources for developing an EA. As a comprehensive, open method for EA, TOGAF 9 complements and can be used in conjunction with other frameworks that are more focused on specific aspects of architecture, such as MDA and ITIL.

The Open Group’s new guide, Using TOGAF to Define and Govern Service-Oriented Architectures, aims to facilitate common understanding of the development of SOA while offering a phased approach to maximizing its business impact based on the popular TOGAF methodology. Let’s take a look at the main takeaways from the guide:

Organization readiness - An enterprise first needs to adopt the principle of service-orientation. However, successful SOA depends on the readiness of the enterprise to become service-oriented. To get started with SOA, the guide recommends conducting a maturity assessment. Such an assessment is available from The Open Group and enables a practitioner to assess an organization’s SOA maturity level and define a roadmap for incremental adoption to maximize business benefits at each stage along the way.

Scope - The size and complexity of an enterprise affects the way its architecture develops. Where there are many different organizational and business models, it is not practical to integrate them within a single architecture. It is therefore generally not appropriate to develop a single, integrated SOA for a large and complex enterprise.

TOGAF defines enterprise as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

The guide highlights an approach for enterprise architects to identify the business areas where SOA will be of greatest benefit and make a significant impact so that they can be prioritized. This approach will help organizations avoid using SOA with the wrong situations to maximize their investment and overall business impact.

Communication, communication, communication - Aspects of TOGAF 9 were extended and enhanced to cover specific service-oriented concepts and terminology such as service contracts. Service contracts formalize the functional and non-functional characteristics of a business service and how it interacts with other business services. This enables a business vocabulary to be derived that allows IT to converse with the business in terms of business process and business services and abstracting away the complexity of the underlying technical services.

Governance - The identification of service and service portfolios is a key task for SOA. The questions of what service and service portfolios the enterprise will have, and how they will be managed must be taken with an enterprise level view.

Just because you have identified a number of services does not automatically mean they will add value to the enterprise and that they should be realized (at least not initially). Governance plays a key role here and the guide recommends the establishment of a SOA governance and creating a linkage to both IT and EA governance in the enterprise.

The Open Group has a wealth of information available in this area, specifically an SOA governance framework that provides context and definitions that enable organizations to understand, customize, and deploy SOA governance.

The relationship between EA and SOA is a powerful and synergistic one. They are key enablers for one another, making EA actionable while making the wider business benefits of SOA obtainable.

SOA is certainly not the only architectural approach that your enterprise will require. But it can smooth the alignment and adoption of other architecture styles (e.g., business process management, event-driven architecture) into an EA framework. So rather than reinvent the wheel, organizations should consider using a well-established framework such as TOGAF to elevate and extend the value of SOA.

The Open Group’s new guide is a must-read for any enterprise architect currently using TOGAF, but remember that it needs to be customized and extended to your enterprises unique situation. Now, if only The Open Group had a guide on using TOGAF to define and govern Cloud Computing!

Stephen Bennett is a senior enterprise architect at Oracle, an author, and a 25-year technologist focused on providing thought leadership, best practices, and architecture guidance around SOA and Cloud Computing. He has co-chaired a number of Work Groups within The Open Group around SOA Governance and TOGAF/SOA.

Comments Off

Filed under Service Oriented Architecture

Monet revisited (or: non-traditional approaches to developing TOGAF® Next)

By Stuart Boardman, Getronics

Right now work is starting on the next major release of TOGAF®, which for now is known as TOGAF® Next. That makes it a very good time to look at what else is going on in the world and what kind of contribution that might make.

A lot of the best ideas come from unexpected directions. Enterprise architects (fortunately) often have passions that don’t have much directly to do with that discipline. Let’s be honest, the best ones almost always do. Peter Bakker recently drew our attention to a current debate in the world of photography and photo journalism. People are using apps like Hipstamatic to make deliberately grungy images – to make the results less “realistic” and more “impressionistic” (same thing Claude Monet and his pals came up with in the late 19th century except they didn’t have apps back then). Apart from the intrinsic interest of the topic, Peter suggested this might be applicable in EA. That made me think. We’ve invested vast amounts of time and effort (and therefore money) in being able to specify things in enormous detail according to increasingly tightly defined models. In fact, people used to complain that those tight models were what TOGAF® lacked. Hmmm. Sometimes the result is not seeing the wood for the trees. Or assuming that detail equals fact. Or getting realism muddled up with reality. Or information with knowledge (never mind wisdom). The Impressionists wanted people to be able to get a feeling of what it was like to be there — not precisely what it looked like at a specific moment in time. So while I’m sure they weren’t thinking about quantum mechanics (that would have been quite an achievement!), they were certainly leaving things open for probabilistic interpretations. Could we do the same in EA – without just producing vagueness? Why not – at least down to a certain level? If you use the Business Model Canvas, for example, you can build up a very meaningful picture of an enterprise’s business model without vast amounts of detail. It provides a lot of knowledge and even some wisdom on the basis of an optimal amount of information. And that has the great benefit of allowing you to fill in the detail where it’s actually going to be useful to you. So why wouldn’t we do something similar in general in EA?

Ross Button is developing an idea he calls Scatter Architecture. You could visualize it as a lot of puzzle pieces that you scatter on a board and see what kind of a picture you can make out of them. They might turn out to fit together in more than one way. That’s actually a good thing, as it probably makes you more adaptable and less exposed to change. Some of the pieces will duplicate each other wholly or partly. Viewed from a TOGAF® perspective we can say that these duplicates occur both on the Enterprise Continuum and on the Solution Continuum. Duplicates are allowed in this architecture. I don’t suppose you’d find them in the Enterprise Strategy or in the Architecture Strategy but you might well find partial duplicates among your propositions, activities, resources and partners – particularly the latter. After all, you probably don’t really want to be dependent on one supplier but that doesn’t mean they’re all exactly alike. So your architecture strategy might even codify that, which means your architecture models will need to take account of it. On the solution side of things it’s just as likely. Ross has explicitly pointed to Cloud as an example of this. Just as in the “real” world, if you can avoid being locked into just one supplier (without the cost implications being too high), you have much more room to manoeuver. The Amazon crash a couple of months ago provided some good positive and negative examples. Moreover, just as in the “real” world, these partners might become part of your value creation process as opposed to just cost elements. So this introduces my second theme, multiplicity.

Louisa Leontiades has just launched a social media integrated business. It’s a great example of how enterprises are changing and why we need to understand them in non-traditional ways. What can we say about her business? Well, it’s an Internet company but it’s not selling technology. It sells real people skills but everything lives in the blogosphere. You can buy her stuff via the site but it’s not an eShop. It’s Louisa’s company but in some ways it’s a virtual enterprise. What does that mean? Well, there will be multiple contributors generating and selling content and the quality and commercial success of the content will shape how the company develops. Or to put it another way, the contributors are not merely suppliers but actually investors, who benefit from the success of the company. Oh and it has its own website but the marketing happens via separate blog sites, via Twitter, Facebook, Google+, LinkedIn – you name it. It’s easy to see then how capturing the architecture of such an enterprise is about capturing the essence and not getting distracted by detail that can change at any moment – exactly due to the multiplicity of contributors and propositions. It’s a daring concept – jumping into the unknown – and of course we won’t see this model in the large enterprise world for quite some time but in the non-profit world or perhaps even in education one could imagine a more rapid adoption. In fact you might reasonably expect to see it adopted in education. It was after all educational and research organizations that gave us the Web in the first place. And back then the web was all about collaboration and sharing – co-creation.

Tom Graves has been looking at extending the Business Model Canvas into Enterprise Architecture as a whole. One part of this is extending it upwards (or outwards – depends how you look at it) to reflect the extended enterprise context in which most organizations “live” today. This involves taking concepts which we already apply to the single enterprise and applying them to a world we don’t control, where multiplicity is the rule and in which our objective is to be an equal partner. This gives rise to relationships, which are both complex and shifting. I would argue that one consequence is that we need to put the emphasis on capturing the entirety of the situation, so we can understand its dynamics and reach (breadth), and we need to avoid the distraction of those details, which we know can and will change without our being consulted (anyone see a similarity to Cloud here?). Another part of what Tom is doing is a mapping with Archimate. I don’t know whether Tom sees it exactly the way I do, but I think one of the advantages is that it combines the impressionist approach with a standardized modeling technique and allows us to provide detail where it’s meaningful and useful. And what it also does is provide a semi-formalized way of using techniques coming from a different discipline within (or along with) familiar EA frameworks. Well, I say “does” but I should say “will do”. It’s work in progress, just like Scatter. Just like TOGAF® Next. You can contribute to these things, influence them or adapt them to your own purposes. You can read and leave them aside but at least you’ll have thought about it. And that in and of itself will enrich your practice.

Stuart Boardman is a Senior Business Consultant with Getronics Consulting where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity. 

1 Comment

Filed under Enterprise Architecture, TOGAF®

PODCAST: Why data and information management remain elusive after decades of deployments; and how to fix it

By Dana Gardner, Interabor Solutions

Listen to this recorded podcast here: BriefingsDirect-Effective Data Management Remains Elusive Even After Decades of Deployments

The following is the transcript of a sponsored podcast panel discussion on the state of data and information management strategies, in conjunction with the The Open Group Conference, Austin 2011.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re listening to BriefingsDirect. Today, we present a sponsored podcast discussion in conjunction with the latest Open Group Conference in Austin, Texas, the week of July 18, 2011. We’ve assembled a distinguished panel to update us on the state of data and information management strategies. We’ll examine how it remains difficult for businesses to get the information they want in the way they can use, and why this has been a persistent problem. We’ll uncover the latest in the framework approach to information and data and look at how an information architect can make a big difference.

Here to help us better understand the role and impact of the information architect and also how to implement a successful data in information strategy is our panel. We’re here with Robert Weisman. He is CEO of Build The Vision Incorporated. Welcome to BriefingsDirect, Robert.

Robert Weisman: Thank you.

Gardner: We’re also here with Eugene Imbamba. He is Information Management Architect in IBM‘s Software Group. Welcome, Eugene.

Eugene Imbamba: Thank you very much.

Gardner: And we’re here also with Mei Selvage. She is the Lead in the IBM Community of Information Architects. Welcome to the show, Mei.

Mei Selvage: Thank you for having us.

Gardner: Tell me, Robert, why it is that it’s so hard for IT to deliver information access in the way that businesses really want.

Weisman: It’s the general insensitivity to information management concerns within the industry itself, which is very much becoming much more technology and tool-driven with the actual information not being taken into consideration. As a consequence, a lot of the solutions might work, but they don’t last, and they don’t, generally speaking, get the right information to the right person at the right time. Within The Open Group, we recognized this split about four years ago and that’s one reason that in TOGAF® 9 we redefined that information technology as “The lifecycle management of information and related technology within an organization.” We didn’t want to see an IM/IT split in organizations. We wanted to make sure that the architecture addressed the needs of the entire community, especially those requiring information and knowledge.

Gardner: Eugene, do you think if we focus more on the lifecycle management of information and the architecture frameworks like TOGAF, that we’ll get more to this requirement that business has that single view of reality?

Imbamba: Definitely, focusing on reference architecture methodologies are a good way to get going in the right direction. I don’t think it’s the end of all means to getting there. But, in terms of leveraging what’s been done, some of the architectures that have been developed, whether it’s TOGAF or some of the other artifacts out there, would help organizations, instead of spinning their wheels and reinventing the wheel, start building some of the foundational capabilities needed to have an enterprise information architecture.

Getting to the finish line

As a result, we’re seeing that each year with information management, projects starting up and projects collapsing for various reasons, whether it’s cost or just the process or people in place. Leveraging some of these artifacts, methods, and reference architectures is a way to help get started, and of course employing other areas of the information management disciplines to help get to the finish line.

Gardner: Mei, when it comes to learning from those that have done this well, what do we know about what works when it comes to data and information management? What can we point to and say, “Without question, moving in this direction is allowing us to be inclusive, move beyond just the data and databases, and get that view that the business is really looking for?”

Selvage: Eugene and I had a long debate over how we know that we’ve delivered a successful information architecture. Our conclusion comes out three plus one. The first piece is just like any strategy roadmap. You need to have a vision and strategy. To have a successful information architecture vision you really have to understand your business problem and your business vision. Then, you use applicable, proven referenced architecture and methodology to support that.

Once you have vision, then you come to the execution. How do you leverage your existing IT environments, integrates with them, keep good communication, and use the best practices? Finally, you have to get implemented on time and on schedule within the budget — and the end-user is satisfied.

Those are three parts. Then, the plus part is data governance, not just one-time project delivery. You’ll have to make sure that data governance is getting consistently implemented across the projects.

Gardner: How about in the direction of this organizational definition of what works and what doesn’t work? How important is it rather for an information architect role to emerge? Let’s start with you, Robert. Then, I’d like to take this to all of you. What is it about the information architect role that can play an important element here?

Weisman: The information architect will soon be called the knowledge architect to start realizing some of the promise that was seen in the 1980s and in the 1990s. The information architect’s role is essentially is to harmonize all manner of information and make sure it’s properly managed and accessible to the people who are authorized to see it. It’s not just the information architect. He has to be a team player, working closely with technology, because more and more information will be not just machine-readable, but machine-processable and interpretable. So he has to work with the people not only in technology, but with those developing applications, and especially those dealing with security because we’re creating more homogenous enterprise information-sharing environments with consolidated information holdings.

The paradigm is going to be changing. It’s going to be much more information-centric. The object-oriented paradigm, from a technical perspective, meant the encapsulation of the information. It’s happened, but at the process level.

When you have a thousand processes in the organization, you’ve got problems. Whereas, now we’d be looking at encapsulation of the information much more at the enterprise level so that information can be reused throughout the organization. It will be put in once and used many times.

Quality of information

The quality of the information will also be addressed through governance, particularly incorporating something called data stewardship, where people would be accountable, not only for the structure of the information but for the actual quality of the informational holdings.

Gardner: Thank you. Eugene, how do you see the role of the information architect as important in solidifying people’s thinking about this at that higher level, and as Robert said, being an advocate for the information across these other disciplines?

Imbamba: It’s inevitable that this role will definitely emerge and is going to take a higher-level position within organizations. Back to my earlier comment about information really becoming an issue, we have lots of information. We have variety of information and varied velocity of information requirements.

We don’t have enough folks today who are really involved in this discipline and some of the projections we have are within the next 20 years, we’re going to have a lot more information that needs to be managed. We need folks who are engaged in this space, folks who understand the space and really can think outside the box, but also understand what the business users want, what they are trying to drive to, and be able to provide solutions that really not only look at the business problem at hand but also what is the organization trying to do.

The role is definitely emerging, and within the next couple of years, as Robert said, the term might change from information architects to knowledge architects, based on where information is and what information provides to business.

Gardner: Mei, how far along are we actually on this definition and even professionalization of the information architect role?

Selvage: I’d like to share a little bit of what IBM is doing internally. We have a major change to our professional programs and certification programs. We’ve removed IT out of architect as title. We just call architect. Under architect we have business architecture, IT architecture, and enterprise architecture. Information architecture falls under IT architecture. Even though we were categorized one of the sub components of IT architecture.

Information architect, in my opinion, is more business-friendly than any other professionals. I’m not trying to put others down, but a lot of new folks come from data modeling backgrounds. They really have to understand business language, business process, and their roles.

When we have this advantage, we need to leverage those and not just keep thinking about how I create database structures and how I make my database perform better. Rather, my tasks today contribute to my business. I want to doing the right thing, rather than doing the wrong things sooner.

IBM reflects an industry shift. The architect is a profession and we all need to change our mindsets to be even broader.

Delivering business value

Weisman: I’d like to add to that. I fully agree, as I said, that The Open Group has created TOGAF 9 as a capability-based planning paradigm for the business planning. IM and IT are just two dimensions of that overall capability, and everything is pushed toward the delivery of business value.

You don’t have to align IM/IT with the business. IM and IT become an integral part of the business. This came out of the defense world in many cases and it has proven very successful.

IM, IT, and all of the architecture domains are going to have to really understand the business for that. It’ll be an interesting time in the next couple of years in the organizations that really want to derive competitive advantage from their information holdings, which is certainly becoming a key differentiator amongst large companies.

Gardner: Robert, perhaps while you’re talking about The Open Group, you could update us a bit on what took place at the Austin Conference, particularly vis-à-vis the workgroups. What was the gist of the development and perhaps any maturation that you can point to?

Weisman: We had some super presentations, in particular the one that Eugene and Mei gave that addressed information architecture and various associated processes and different types of sub- architectures/frameworks as well.

The Information Architecture Working Group, which is winding down after two years, has created a series of whitepapers. The first one addressed the concerns of the data management architecture and maps the data management body of knowledge processes to The Open Group Architecture Framework. That whitepaper went through final review in the Information Architecture Working Group in Austin.

We have an Information Architecture Vision paper, which is an overall rethinking of how information within an organization is going to be addressed in a holistic manner, incorporating what we’d like to think as all of the modern trends, all types of information, and figure out some sort of holistic way that we can represent that in an architecture. The vision paper is right now in the final review. Following that, we’re preparing a consolidated request for change to the TOGAF 9 specification. The whitepapers should be ready and available within the next three months for public consultation. This work should address many significant concerns in the domain of information architecture and management. I’m really confident the work that working group has done has been very productive.

Gardner: Now, you mentioned that Mei and Eugene delivered a presentation. I wonder if we can get an overview, a quick summary of the main points. Mei, would you care to go first?

Selvage: We’ve already talked a lot about what we have described in our presentation. Essentially, we need to understand what it means to have a successful solution information architecture. We need to leverage all those best practices, which come in a form of either a proven reference architecture or methodology, and use that to achieve alignment within the business. Eugene, do you have anything you want to specifically point out in our presentation?

Three keys

Imbamba: No, just to add to what you said. The three keys that we brought were the alignment of business and IT, using and leveraging reference architectures to successfully implement information architectures, and last was the adoption of proven methodology.

In our presentation, we defined these constructs, or topics, based on our understanding and to make sure that the audience had a common understanding of what these components meant. Then, we gave examples and actually gave some use cases of where we’ve seen this actually happen in organizations, and where there has been some success in developing successful projects through the implementation of these methods. That’s some of what we touched on.

Weisman: Just as a postscript from The Open Group, we’re coming with an Information Architecture and Planning Model. We have a comprehensive definition of data and information and knowledge; we’ve come up with a good generic lifecycle that can be used by all organizations. And, we addressed all the issues associated with them in a holistic way with respect to the information management functions of governance, planning, operations, decision support and business intelligence, records and archiving, and accessibility and privacy.

This is one of the main contributions that these whitepapers are going to provide is a good planning basis for the holistic management of all manner of information in the form of a complete model.

Gardner: We’ve heard about how the amount of data is going to be growing exponentially, perhaps 44 times in less than 10 years, and we’ve also heard that knowledge, information, and your ability to exploit it could be a huge differentiator in how successful you are in business. I even expect that many businesses will make knowledge and information of data part of their business, part of their major revenue capabilities — a product in itself.

Let’s look into the future. Why will the data and information management professionalization, this role of the information architect be more important based on some of the trends that we expect? Let’s start with you, Robert. What’s going to happen in the next few year that’s going to make it even more important to have the holistic framework, strategic view of data information?

Weisman: Right now, it’s competitive advantage upon which companies may rise and fall. Harvard Business School Press, Davenport in particular, has produced some excellent books on competitive analytics and the like, with good case studies. For example, a factory halfway through construction is stopped because they didn’t have timely access to the their information indicating the factory didn’t even need to be constructed. This speaks of information quality.

In the new service-based rather than industry-based economic paradigm, information will become absolutely key. With respect to the projected increase of information available, I actually see a decrease in information holdings within the enterprise itself.

This will be achieved through a) information management techniques, you will actually get rid of information; b) you will consolidate information; and c) with paradigms such as cloud, you don’t necessarily have to have information within the organization itself.

More with less

So you will be dealing with information holdings, that are accessible by the enterprise, and not necessarily just those that are held by the enterprise. There will also be further issues such as knowledge representation and the like, that will become absolutely key, especially with demographics as it stands now. We have to do more with less.

The training and professionalization of information architecture, or knowledge architecture, I anticipate will become key. However, knowledge architects cannot be educated totally in a silo, they also have to have a good understanding of the other architecture domains. A successful enterprise architect must understand all the the other architecture domains.

Gardner: Eugene, how about you, in terms of future trends that impact the increased importance of this role in this perspective on information?

Imbamba: From an IBM perspective, we’ve seen over the last 20 years organizations focusing on what I call an “application agenda,” really trying to implement enterprise resource planning (ERP) systems, supply chain management systems, and these systems have been very valuable for various reasons, reducing cost, bringing efficiencies within the business.

But, as you know, over the last 20 years, a lot of companies now have these systems in place, so the competitive advantage has been lost. So what we’re seeing right now is companies focusing on an information agenda, and the reason is that each organization has information about its customers, its products, its accounts like no other business would have.

So, what we’re seeing today is leveraging that information for competitive advantage, trying to optimize your business, gleaning the information that you have so that you can understand the relationships between your customers, between your partners, your suppliers, and optimize that to deliver the kinds of services and needs, the business wants and the customer’s needs. It’s a focus from application agenda to an information agenda to try and push what’s going on in that space.

Gardner: Mei, last word to you, future trends and why would they increase the need for the information architecture role?

Selvage: I like to see that from two perspectives. One is from the vendor perspective, just taking IBM as an example. The information management brand is the one that has the largest software products, which reflects market needs and the market demands. So there are needs to have information architects who are able to look over all those different software offerings in IBM and other major vendors too.

From the customer perspective, where I see a lot of trends is that many outsource basic database administration, kind of a commodity or activity out to a third-party where they keep the information architects in-house. That’s where we can add in the value. We can talk to the business. We can talk to the other components of IT, and really brings things together. That’s a trend I see more organizations are adopting.

Gardner: Very good. We’ve been discussing the role and impact of an information architect and perhaps how to begin to implement a more successful data and information strategy.

This comes to you as a sponsored podcast in conjunction with The Open Group Conference in Austin, Texas in the week of July 18, 2011. I’d like to thank our guests. We’ve been joined by Robert Weisman, CEO of Build The Vision Incorporated. Thanks so much, Robert.

Weisman: You’re very welcome. Thank you for inviting.

Gardner: And we’ve been here with Eugene Imbamba. He is Information Management Architect in IBM Software Group. Thank you, Eugene.

Imbamba: Thank you for having me.

Gardner: And Mei Selvage, she is Lead of the IBM Community of Information Architects. Thanks to you as well.

Selvage: You’re welcome. Thank you too.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. Thanks to our viewers and listeners as well, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com.

Copyright The Open Group 2011. All rights reserved.

Dana Gardner is the Principal Analyst at Interarbor Solutions, which identifies and interprets the trends in Services-Oriented Architecture (SOA) and enterprise software infrastructure markets. Interarbor Solutions creates in-depth Web content and distributes it via BriefingsDirect™ blogs, podcasts and video-podcasts to support conversational education about SOA, software infrastructure, Enterprise 2.0, and application development and deployment strategies.

Comments Off

Filed under Data management

How strategic planning relates to Enterprise Architecture

By Serge Thorn, Architecting the Enterprise

TOGAF® often refers to Strategic Planning without specifying the details of what it consists of. This document explains why there is a perfect fit between the two.

Strategic Planning means different things to different people. The one constant is its reference to Business Planning which usually occurs annually in most companies. One of the activities of this exercise is the consideration of the portfolio of projects for the following financial year, also referred to as Project Portfolio Management (PPM). This activity may also be triggered when a company modifies its strategy or the priority of its current developments.

Drivers for Strategic Planning may be

  • New products or services
  • A need for greater business flexibility and agility
  • Merger & acquisition
  • Company’s reorganization
  • Consolidation of manufacturing plants, lines of business, partners, information systems
  • Cost reduction
  • Risk mitigation
  • Business process management initiatives
  • Business process outsourcing
  • Facilities outsourcing or insourcing
  • Off-shoring

Strategic Planning as a process may include activities such as:

1. The definition of the mission and objectives of the enterprise

Most companies have a mission statement depicting the business vision, the purpose and value of the company and the visionary goals to address future opportunities. With that business vision, the board of the company defines the strategic (e.g. reputation, market share) and financial objectives (e.g. earnings growth, sales targets).

2. Environmental analysis

The environmental analysis may include the following activities:

  • Internal analysis of the enterprise
  • Analysis of the enterprise’s industry
  • A PEST Analysis (Political, Economic, Social, and Technological factors). It is very important that an organization considers its environment before beginning the marketing process. In fact, environmental analysis should be continuous and feed all aspects of planning, identify the strengths and weaknesses, the opportunities and threats (SWOT)

3. Strategy definition

Based on the previous activities, the enterprise matches strengths to opportunities and addressing its weaknesses and external threats and elaborate a strategic plan. This plan may then be refined at different levels in the enterprise. Below is a diagram explaining the various levels of plans.

To build that strategy, an Enterprise Strategy Model may be used to represent the Enterprise situation accurately and realistically for both past and future views. This can be based on Business Motivation Modeling (BMM) which allows developing, communicating and managing a Strategic Plan. Another possibility is the use of Business Model Canvas which allows the company to develop and sketch out new or existing business models. (Refer to the work from Alexander Osterwalder).

The model’s analyses should consider important strategic variables such as customers demand expectations, pricing and elasticity, competitor behavior, emissions regulations, future input, and labor costs.

These variables are then mapped to the main important business processes (capacity, business capabilities, constraints), and economic performance to determine the best decision for each scenario. The strategic model can be based on business processes such as customer, operation or background processes. Scenarios can then are segmented and analyzed by customer, product portfolio, network redesign, long term recruiting and capacity, mergers and acquisitions to describe Segment Business Plans.

4. Strategy Implementation

The selected strategy is implemented by means of programs, projects, budgets, processes and procedures. The way in which the strategy is implemented can have a significant impact on whether it will be successful, and this is where Enterprise Architecture may have a significant role to play. Often, the people formulating the strategy are different from those implementing it. The way the strategy is communicated is a key element of the success and should be clearly explained to the different layers of management including the Enterprise Architecture team.

To support that strategy, different levels or architecture can be considered such as strategic, segment or capability architectures.

This diagram below illustrates different examples of new business capabilities linked to a Strategic Architecture.

It also illustrates how Strategic Architecture supports the enterprise’s vision and the strategic plan communicated to an Enterprise Architecture team.

Going to the next level allows better detail the various deliverables and the associated new business capabilities. The segment architecture maps perfectly to the Segment Business Plan.

5. Evaluation and monitoring

The implementation of the strategy must be monitored and adjustments made as required.

Evaluation and monitoring consists of the following steps:

  • Definition of KPIs, measurement and metrics
  • Definition of target values for these KPIs
  • Perform measurements
  • Compare measured results to the pre-defined standard
  • Make necessary changes

Strategic Planning and Enterprise Architecture should ensure that information systems do not operate in a vacuum. At its core, TOGAF® 9 uses/supports a strong set of guidelines that were promoted in the previous version, and have surrounded them with guidance on how to adopt and apply TOGAF® to the enterprise for Strategic Planning initiatives. The ADM diagram below clearly indicates the integration between the two processes.

The company’s mission and vision must be communicated to the Enterprise Architecture team which then maps Business Capabilities to the different Business Plans levels.

Many Enterprise Architecture projects are focused at low levels but should be aligned with Strategic Corporate Planning. Enterprise Architecture is a critical discipline, one Strategic Planning mechanism to structure an enterprise. TOGAF® 9 is without doubt an effective framework for working with stakeholders through Strategic Planning and architecture work, especially for organizations who are actively transforming themselves.

This article has previously appeared in Serge Thorn’s personal blog and appears here with his permission.

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 has more than 20 years of experience in Banking and Finance and 5 years of experience in the Pharmaceuticals industry. Among various roles, he has been responsible for the Architecture team in an international bank, where he gained wide experience in the deployment and management of information systems in Private Banking, Wealth Management, and also in IT architecture domains such as the Internet, dealing rooms, inter-banking networks, and Middle and Back-office. He then took charge of IT Research and Innovation (a function which consisted of motivating, encouraging creativity, and innovation in the IT Units), with a mission to help to deploy a TOGAF based Enterprise Architecture, taking into account the company IT Governance Framework. He also chaired the Enterprise Architecture Governance worldwide program, integrating the IT Innovation initiative in order to identify new business capabilities that were creating and sustaining competitive advantage for his organization. Serge has been a regular speaker at various conferences, including those by The Open Group. His topics have included, “IT Service Management and Enterprise Architecture”, “IT Governance”, “SOA and Service Management”, and “Innovation”. Serge has also written several articles and whitepapers for different magazines (Pharma Asia, Open Source Magazine). He is the Chairman of the itSMF (IT Service Management forum) Swiss chapter and is based in Geneva, Switzerland.

2 Comments

Filed under Enterprise Architecture, TOGAF®

PODCAST: Embracing EA and TOGAF® aids companies in improving innovation, market response and governance

By Dana Gardner, Interabor Solutions

Listen to this recorded podcast here: BriefingsDirect-How to Leverage Advanced TOGAF 9 Use for Business Benefits

The following is the transcript of a sponsored podcast panel discussion on how to leverage advanced concepts in TOGAF® for business benefits, in conjunction with the The Open Group Conference, Austin 2011.

Dana Gardner: Hi, this is Dana Gardner, Principal Analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

Today, we present a sponsored podcast discussion in conjunction with the latest Open Group Conference in Austin, Texas, the week of July 18, 2011. We’ve assembled a panel to examine the maturing use of TOGAF. That’s The Open Group Architecture Framework, and how enterprise architects and business leaders are advancing and exploiting the latest Framework, Version 9. We’ll further explore how the full embrace of TOGAF, its principles and methodologies, are benefiting companies in their pursuit of improved innovation, responsiveness to markets, and operational governance. Is enterprise architecture (EA) joining other business transformation agents as a part of a larger and extended strategic value? How? And what exactly are the best practitioners of TOGAF getting for their efforts in terms of business achievements?

Here with us to delve into advanced use and expanded benefits of EA frameworks and what that’s doing for their user organizations is Chris Forde, Vice President of Enterprise Architecture and Membership Capabilities for The Open Group, based in Shanghai. Welcome, Chris.

Chris Forde: Good morning, Dana.

Gardner: We’re also here with Jason Uppal. He is the Chief Architect at QR Systems, based in Toronto. Welcome, Jason.

Jason Uppal: Thank you, Dana.

Gardner: Jason, let’s cut to the quick here. We hear an awful lot about architecture. We hear about planning and methodologies, putting the right frameworks in place, but is TOGAF having an impact on the bottom line in the organizations that are employing it?

Uppal: One of the things with a framework like a TOGAF is that, on the outside, it’s a framework. At the same time, when you apply this along with the other disciplines, it’s making big difference in the organization, partially it’s because it’s allowing the IT organizations to step up to the plate within the core enterprise as a whole and ask how they can actually exploit the current assets that they already have. And secondly, how do they make sure the new assets that they do bring into the organization are aligned to the business needs.

One of the examples where EA has a huge impact in many of the organizations that I have experience with is that, with key EA methods, we’re able to capture the innovation that exists in the organization and make that innovation real, as opposed to just suggestions that are thrown in a box, and nobody ever sees them.

Gardner: What is it about capturing that innovation that gets us to something we can measure in terms of an achievable bottom-line benefit?

Evolve over time

Uppal: Say you define an end-to-end process using architecture development method (ADM) methods in TOGAF. What it does is give me a way to capture that innovation at the lowest level and then evolve it over time. Those people who are part of the innovation at the beginning see their innovation or idea progressing through the organization, as the innovation gets aligned to value statements, and value statements get aligned to their capabilities, and the strategies, and the projects, and hence to the end of the day.

Therefore, if I make a suggestion of some sort, that innovation or idea is seen throughout the organization through the methods like ADM, and the linkage is explicit and very visible to the people. Therefore, they feel comfortable that their ideas are going somewhere, they are just not getting stuck.

Forde: There’s an additional point here, Dana, to underscore the answer that Jason gave to your question. In the end result, what you want to be seeing out of your architectural program is moving the KPIs for the business, the business levers that they are expecting to be moved out. If that is related to cost reduction or is related to top-line numbers or whatever, that explicit linkage through to the business levers in an architecture program is critical.

Gardner: Chris, you have a good view on the global markets and the variability of goals here. Many companies are looking to either cut cost or improve productivity. Others are looking to expand. Others are looking to manage how to keep operations afloat. There are so many different variables. How do things like the TOGAF 9 and EA have a common benefit to all of those various pursuits? What is the common denominator that makes EA so powerful?

Forde: Going back to the framework reference, what we have with TOGAF 9 is a number of assets, but primarily it’s a tool that’s available to be customized, and it’s expected to be customized.

If you come to the toolset with a problem, you need to focus the framework on the area that’s going to help you get rapid value to solving your particular problem set. So once you get into that particular space, then you can look at migrating out from that entry point, if that’s the approach, to expanding your use of the framework, the methods, the capabilities, that are implicit and explicit in the framework to address other areas. You can start at the top and work your way down through the framework, from this kind of über value proposition, right down through delivery to the departmental level or whatever. Or, you can come into the bottom, in the infrastructure layer, in IT for example, and work your way up. Or, you can come in at the middle. The question is what is impeding your company’s growth or your department’s growth, if those are the issues that are facing you.

One of the reasons that this framework is so useful in so many different dimensions is that it is a framework. It’s designed to be customized, and is applicable to many different problems.

Gardner: Back to you, Jason. When we think about a beginning effort, perhaps a crawl-walk- run approach to EA and TOGAF, the promise is that further development, advancement, understanding, implementation will lead to larger, more strategic goals.

Let’s define what it means to get to that level of maturity. When we think about an advanced user of TOGAF, what does that mean? Then, we’ll get into how they can then leverage that to further goals. But, what do we really mean by an advanced user at this point?

Advanced user

Uppal: When we think about an advanced user, in our practice we look at it from different points of view and ask what value I’m delivering to the organization. It could very well be delivering value to a CTO in the organization. That is not to say that’s not an advanced user, because that’s strictly focused on technology.

But then, the CTO focus is that it allows us to focus on the current assets that are under deployment in the organization. How do you get the most out of them? So, that’s an advanced user who can figure out how to standardize and scale those assets into a scalable way so therefore they become reusable in the organization. As we move up the food chain from very technology-centric view of a more optimized and transformed scale, advanced user at that point is looking at and saying that now I have a framework like TOGAF, that advanced user has all these tools in their back pocket.

Now, depending on the stakeholder that they’re working with, be that a CEO, a CFO, or a junior manager in the line of business, I can actually focus them on defining a specific capability that they are working towards and create transition roadmaps. Once those transition roadmaps are established, then I can drive that through. An advanced user in the organization is somebody who has all these tools available to them, frameworks available to them, but at the same time, are very focused on a specific value delivery point in their scope.

One beauty of TOGAF is that, because we get to define what enterprise is and we are not told that we have to interview the CEO on day one, I can define an enterprise from a manager’s point of view or a CFO’s point of view and work within that framework. That to me is an advanced user.

Gardner: When we talk about applied architecture, what does that mean? How is it that we move from concept into execution?

Uppal: The frameworks that we have are well thought-out frameworks. So, it moves the conversation away from this framework debate and very quickly moves our conversation into what we do with it. When we talk about a framework like TOGAF, now I can look at and say that if I wanted to apply it now, I have an executive who has defined a business strategy, which typically is a two page PowerPoint presentation, sometimes accompanied by Excel. That’s a good starting point for an enterprise architect. Now, I use methods like TOGAF to define the capabilities in that strategy that they are trying to optimize, where they are, and what they want to transition to.

Very creative

This is where a framework allows me to be very creative, defining the capabilities and the transition points, and giving a roadmap to get to those transitions. That is the cleverness and cuteness of architecture work, and the real skills of an architect comes into, not in defining the framework, but defining the application of the framework to a specific business strategy.

Gardner: Jason, we mentioned that there is a great deal of variability in what different companies in different regions and in different industries need to accomplish, but one of the common questions I get a lot these days is what to outsource and what to manage internally and how to decide the boundaries between a core competency and extended outsourcing or hybrid computing types of models? How does the applied architecture come to the rescue, when this sort of question, which I think is fundamental to an enterprise, comes up?

Uppal: That’s a great question. That’s one of the area where if architects do their job well, we can help the organization move much further along. Because, what we do in the business space, and we have done it many times with the framework, is to look at the value chain of the organization. And looking at the value chain, then to map that out to the capabilities required.

Once we know those capabilities, then I can squarely put that question to the executives and say, “Tell me which capability you want to be the best at. Tell me what capability you want to lead the market in. And, tell me which capability you want to be mediocre and just be at below the benchmark in industry.” Once I get an understanding of which capability I want to be the best at, that’s where I want to focus my energy. Those ones that I am prepared to live with being mediocre, then I can put another strategy into place and ask how I outsource these things, and focus my outsourcing deal on the cost and service.

This is opposed to having very confused contract with the outsourcer, where one day I’m outsourcing for the cost reasons. The other day, I’m outsourcing for growth reasons. It becomes very difficult for an organization to manage the contracts and bend it to provide the support. That conversation, at the beginning, is getting executives to commit to which capability they want to be best at. That is a good conversation for an enterprise architect.

My personal experience has been that if I get a call back from the executive, and they say they want to be best at every one of them, then I say, “Well, you really don’t have a clue what you are talking about. You can’t be super fast and super good at every single thing that you do.”

Gardner: So making those choices is what’s critical. Some of the confusion I also hear about in the field is how to do a cost-benefit analysis about what processes I might keep internal, versus either hybrid or external source processes?

Is there something about the applied architecture and TOGAF 9 that sets up some system of record or methodology approach that allows that cost-benefit analysis of these situations to be made in advance? Is there anything that the planning process brings to the table in trying to make proper decisions about sourcing?

Capability-based planning

Uppal: Absolutely. This is where the whole of our capability-based planning conversation is. It was introduced in TOGAF 9, and we got more legs to go into developing that concept further, as we learn how best to do some of these things.

When I look at a capability-based planning, I expect my executives to look at it from a point of view and ask what are the opportunities and threats. What it is that you can get out there in the industry, if you have this capability in your back pocket? Don’t worry about how we are going to get it first, let’s decide that it’s worth getting it.

Then, we focus the organization into the long haul and say, well, if we don’t have this capability and nobody in the industry has this capability, if we do have it, what will it do for us? It provides us another view, a long-term view, of the organization. How are we going to focus our attention on the capabilities?

One of the beauties of doing EA is, is that when we start EA at the starting point of a strategic intent, that gives us a good 10-15 year view of what our business is going to be like. When we start architecture at the business strategy level, that gives us a six months to five-year view.

Enterprise architects are very effective at having two views of the world — a 5, 10, or 15 year view of the world, and a 6 months to 3 year view of the world. If we don’t focus on the strategic intent, we’ll never know what is possible, and we would always be working on what is possible within our organization, as opposed to thinking of what is possible in the industry as a whole.

Gardner: So, in a sense, you have multiple future tracks or trajectories that you can evaluate, but without a framework, without an architectural approach, you would never be able to have that set of choices before you.

Chris Forde, any thoughts on what Jason’s been saying in terms of the sourcing and cost benefits and risks analysis that go into that?

Forde: In the kinds of environment that most organizations are operating in — government, for- profit, not-for-profit organizations — everybody is trying to understand what it is they need to be good at and what it is their partners are very good at that they can leverage. Their choices around this are of course critical.

One of the things that you need to consider is that if you are going to give x out and have the power to manage that and operate whatever it is, whatever process it might be, what do you have to be good at in order to make them effective? One of the things you need to be good at is managing third parties. One of the advanced uses of an EA is applying the architecture to those management processes. In the maturity of things you can see potentially an effective organization managing a number of partners through an architected approach to things. So when we talked about what do advanced users do, what I am offering is that an advanced use of EA is in the application of it to third-party management.

Gardner: So the emphasis is on the process, not necessarily who is executing on that process?

Framework necessary

Forde: Correct, because you need a framework. Think about what most major Fortune 500 companies in the United States do. They have multiple, multiple IT partners for application development and potentially for operations. They split the network out. They split the desktop out. This creates an amazing degree of complexity around multiple contracts. If you have an integrator, that’s great, but how do you manage the integrator?

There’s a whole slew of complex problems. What we’ve learned over the years is that the original idea of “outsourcing,” or whatever the term that’s going to be used, we tend to think of that in the abstract, as one activity, when in fact it might be anywhere from 5-25 partners. Coordinating that complexity is a major issue for organizations, and taking an architected approach to that problem is an advanced use of EA.

Gardner: So stated another way, Jason, the process is important, but the management of processes is perhaps your most important core competency. Is that fair, and how does EA support that need for a core competency of managing processes across multiple organizations?

Uppal: That’s absolutely correct. Chris is right. For example, there are two capabilities an organization decided on, one that they wanted to be very, very good at.

We worked with a large concrete manufacturing company in the northern part of the country. If you’re a concrete manufacturing company, your biggest cost is the cement. If you can exploit your capability to optimize the cement and substitute products with the chemicals and get the same performance, you can actually get a lot more return and higher margins for the same concrete.

In this organization, the concrete manufacturing process itself was core competency. That had to be kept in-house. The infrastructure is essential to make the concrete, but it wasn’t the core competency of the organization. So those things had to be outsourced. In this organization we have to build a process — how to manage the outsourcer and, at the same time, have a capability and a process. Also, how to become best concrete manufacturers. Those two essential capabilities were identified.

An EA framework like TOGAF actually allows you to build both of those capabilities, because it doesn’t care. It just thinks, okay, I have a capability to build, and I am going to give you a set of instructions, the way you do it. The next thing is the cleverness of the architect — how he uses his tools to actually define the best possible solutions.

Gardner: Of course, it’s not just enough to identify and implement myriad sourcing or complex sourcing activities, but you need to monitor and have an operational governance oversight capability as well. Is there something in TOGAF 9 specifically that lends itself to taking this into the operational and then creating ongoing efficiencies as a result?

Uppal: Absolutely, because this is one of the areas where in ADM, when we get back to our implementation of governance, and post implementation of governance, value realization, how do we actually manage the architecture over the life of it? This is one of the areas where TOGAF 9 has done a considerably good job, and we’ve still got a long way to go in how we actually monitor and what value is being realized.

Very explicit

Our governance model is very explicit about who does what and when and how you monitor it. We extended this conversation using TOGAF 9 many times. At the end, when the capability is deployed, the initial value statement that was created in the business architecture is given back to the executive who asked for that capability.

We say, “This is what the benefits of these capabilities are and you signed off at the beginning. Now, you’re going to find out that you got the capability. We are going to pass this thing into strategic planning next year, because for next year’s planning starting point, this is going to be your baseline.” So not only is the governance just to make sure it’s via monitoring, but did we actually get the business scores that we anticipated out of it.

Gardner: Another area that’s of great interest to me nowadays is looking at the IT organization as they pursue things like Cloud, software as a service (SaaS), and hybrid models. Do they gather a core competency at how to manage these multiple partners, as Chris pointed out, or does another part of the company that may have been dealing with outsourcing at a business process level teach the IT department how to do this?

Any sense from either of our panelists on whether IT becomes a leader or a laggard in how to manage these relationships, and how important is managing the IT element of that in the long run? Let’s start with you, Jason.

Uppal: It depends on the industry the IT is in. For example, if you’re an organization that is very engineering focused, engineers have a lot more experience managing outsourcing deals than IT organizations do. In that case, the engineering leads this conversation.

But in most organizations, which are service-oriented organizations, engineering has not been a primary discipline, and IT has a lot of experience managing outside contracts. In that case, the whole Cloud conversation becomes a very effective conversation within the IT organization.

When we think about cloud, we have actually done Cloud before. This is not a new thing, except that before we looked at it from a hosting point of view and from a SaaS point of view. Now, cloud is going in a much further extended way, where entire capability is provided to you. That capability is not only that the infrastructure is being used for somebody else, but the entire industry’s knowledge is in that capability. This is becoming a very popular thing, and rightfully so, not because it’s a sexy thing to have. In healthcare, especially in countries where it’s a socialized healthcare and it’s not monopolized, they are sharing this knowledge in the cloud space with all the hospitals. It’s becoming a very productive thing, and enterprise architects are driving it, because we’re thinking of capabilities, not components.

Gardner: Chris Forde, similar question. How do you see the role of IT shifting or changing as a result of the need to manage more processes across multiple sources?

Forde: It’s an interesting question. I tend to agree with the earlier part of Jason’s response. I am not disagreeing with any of it, actually, but the point that he made about it is that it’s a “it depends” answer.

IT interaction

Under normal circumstances the IT organizations are very good at interacting with other technology areas of the business. From what I’ve seen with the organizations I have dealt with, typically they see slices of business processes, rather than the end-to-end process entirely. Even within the IT organizations typically, because of the size of many organizations, you have some sort of division of responsibilities. As far as Jason’s emphasis on capabilities and business processes, of course the capabilities and processes transcend functional areas in an organization.

To the extent that a business unit or a business area has a process owner end to end, they may well be better positioned to manage the BPMO type of things. If there’s a heavy technology orientation around the process outsourcing, then you will see the IT organization being involved to one extent or another.

The real question is, where is the most effective knowledge, skill, and experience around managing these outsourcing capabilities? It may be in the IT organization or it may be in the business unit, but you have to assess where that is.

That’s one of the functions that the architecture approaches. You need to assess what it is that’s going to make you successful in this. If what you need happens to be in the IT organization, then go with that ability. If it is more effective in the business unit, then go with that. And perhaps the answer is that you need to combine or create a new functional organization for the specific purpose of meeting that activity and outsource need.

I’m hedging a little bit, Dana, in saying that it depends.

Gardner: It certainly raises some very interesting issues. At the same time that we’re seeing this big question mark around sourcing and how to do that well, we’re also in a period where more organizations are being data-driven and looking to have deeper, more accessible, and real-time analytics applied to their business decisions. Just as with sourcing, IT also has an integral role in this, having been perhaps the architects or implementators of warehousing, data marts, and business intelligence (BI).

Back to you Jason. As we enter into a phase where organizations are also trying to measure and get scientific and data-driven about their decisions, how does IT, and more importantly, how does TOGAF and EA come to help them do that?

Uppal: We have a number of experiences like that, Dana. One is a financial services organization. The entire organization’s function is that they manage some 100-plus billion dollars worth of assets. In that kind of organization, all the decision making process is based on the data that they get. And 95 percent of the data is not within the organization. It is vendor data that they’re getting from outside.

So in that kind of conversation, we look and say that the organization needs a capability to manage data. Once we define a capability, then we start putting metrics on this thing. What does this capability need to be able to do?

In this particular example, we put a metric on this and said that the data gets identified in the morning, by the afternoon we bring it into the organization, and by the end of the day we get rid of it. That’s how fast the data has to be procured, transformed into the organization, brought it in, and delivered it to end-use. That end-user makes the decision whether we will never look at the data again.

Data capability

Having that fast speed of data management capability in the organization, and this is one of the areas where architects can take a look at, this is the capability you need. Now I can give you a roadmap to get to that capability.

Gardner: Chris Forde, how do you see the need for a data-driven enterprise coincide with IT and EA?

Forde: For most, if not all, companies, information and data are critical to their operation and planning activities, both on a day-to-day basis, month-to-month, annually, and in longer time spans. So the information needs of a company are absolutely critical in any architected approach to solutioning or value-add type of activities.

I don’t think I would accept the assumption that the IT department is best-placed to understand what those information needs are. The IT organization may be well-placed to provide input into what technologies could be applied to those problems, but if the information needs are normally being applied to business problems, as opposed to technology problems, I would suggest that it is probably the business units that are best-placed to decide what their information needs are and how best to apply them.

The technologist’s role, at least in the model I’m suggesting, is to be supportive in that and deliver the right technology, at the right time, for the right purpose.

Gardner: Then, how would a well-advanced applied architecture methodology and framework help those business units attain their information needs, but also be in a position to exploit IT’s helping hand when needed?

Forde: It’s mostly providing the context to frame the problem in a way that it can be addressed, chunked down to reasonable delivery timeframes, and then marshaling the resources to bring that to reality.

From a pure framework and applied methodology standpoint, if you’re coming at it from an idealized situation, you’re going to be doing it from a strategic business need and you’re going to be talking to the business units about what their capability and functional needs are. And at that time, you’re really in the place of what business processes they’re dealing with and what information they need in order to accomplish what the particular set of goals is.

This is way in advance of any particular technology choice being made. That’s the idealized situation, but that’s typically what most frameworks, and in particular, the TOGAF 9 Framework from The Open Group, would go for.

Gardner: We’re just beginning these conversations about advanced concepts in EA and there are going to be quite a bit more offerings and feedback and collaboration around this subject at The Open Group Conference in Austin. Perhaps before we sign off, Jason, you can give us a quick encapsulation of what you will be discussing in terms of your presentation at the conference.

Uppal: One of the things that we’ve been looking at from the industry’s point of view is saying that this conversation around the frameworks is a done deal now, because everybody accepted that we have good enough frameworks. We’re moving to the next phase of what we do with these frameworks.

In our future conferences, we’re going to be addressing that and saying what people are specifically doing with these frameworks, not to debate the framework itself, but the application of it.

Continuous planning

In Austin we’ll be looking at how we’re using a TOGAF framework to improve ongoing annual business and IT planning. We have a specific example that we are going to bring out where we looked at an organization that was doing once-a-year planning. That was not a very effective way for the organizations. They wanted to change it to continuous planning, which means planning that happens throughout the year.

We identified four or five very specific measurable goals that the program had, such as accuracy of your plan, business goals being achieved by the plan, time and cost to manage and govern the plan, and stakeholders’ satisfaction. Those are the areas that we are defining as to how the TOGAF like framework will be applied to solve a specific problem like enterprise planning and governance.

That’s something we will be bringing to our conference in Austin and that event will be held on a Sunday. In the future, we’ll be doing a lot more of those specific applications of a framework like a TOGAF to a unique set of problems that are very tangible and they very quickly resonate with the executives, not in IT, but in the entire organization.

Forde: Can I follow along with a little bit of a plug here, Dana.

Gardner: Certainly.

Forde: Jason is going to be talking as a senior architect on the applied side of TOGAF on this Sunday. For the Monday plenary, this is basically the rundown. We have David Baker, a Principal from PricewaterhouseCoopers, talking about business driven architecture for strategic transformations.

Following that, Tim Barnes, the Chief Architect at Devon Energy out of Canada, covering what they are doing from an EA perspective with their organization.

Then, we’re going to wrap up the morning with Mike Walker, the Principal Architect for EA Strategy and Architecture at Microsoft, talking about IT Architecture to the Enterprise Architecture.

This is a very powerful lineup of people addressing this business focus in EA and the application of it for strategic transformations, which I think are issues that many, many organizations are struggling with.

Gardner: Looking at, again, the question I started us off with, how do TOGAF and EA affect the bottom line? We’ve heard about how it affects the implementation for business transformation processes. We’ve talked about operational governance. We looked at how sourcing, business process management and implementation, and ongoing refinement are impacted. We also got into data and how analytics and information sharing are affected. Then, as Jason just mentioned, planning and strategy as a core function across a variety of different types of business problems.

So, I don’t think we can in any way say that there’s a minor impact on the bottom line from this. Last word to you, Jason.

Uppal: This is a time now for the enterprise architects to really step up to the plate and be accountable for real performance influence on the organization’s bottom line.

If we can improve things like exploiting assets better today than what we have, improve our planning program, and have very measurable and unambiguous performance indicator that we’re committing to, this is a huge step forward for enterprise architects and moving away from technology and frameworks to real-time problems that resonate with executives and align to business and in IT.

Gardner: Well, great. You’ve been listening to a sponsored podcast discussion in conjunction with The Open Group Conference in Austin, Texas, the week of July 18, 2011.

I would like to thank our guests. We have been joined by Chris Forde, Vice President of Enterprise Architecture and Membership Capabilities for The Open Group. Thanks, Chris.

Forde: Thanks, Dana.

Gardner: And also Jason Uppal. He is the Chief Architect at QR Systems. Thank you, Jason.

Uppal: Thank you, Dana.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. Thanks for joining, and come back next time.

Jason Uppal will be presenting “Advanced Concepts in Applying TOGAF 9” at The Open Group Conference, Austin, July 18-22. Join us for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Copyright The Open Group 2011. All rights reserved.

Dana Gardner is the Principal Analyst at Interarbor Solutions, which identifies and interprets the trends in Services-Oriented Architecture (SOA) and enterprise software infrastructure markets. Interarbor Solutions creates in-depth Web content and distributes it via BriefingsDirect™ blogs, podcasts and video-podcasts to support conversational education about SOA, software infrastructure, Enterprise 2.0, and application development and deployment strategies.

Comments Off

Filed under Enterprise Architecture, TOGAF®

EA Fundamentalism

By Stuart Boardman, Getronics

It’s an unfortunate fact that when times get tough, the tough, rather than get going, tend to pick on other people. What we see is that most formal and informal groups tend to turn inwards and splinter into factions, each possessing the only true gospel. When times are good, we’re all too busy doing what we actually want to do to want to waste time sniping at other folks.

Maybe this isn’t the reason but it strikes me that in the EA blogosphere at the moment (e.g. the EA group on LinkedIn) every discussion seems to deteriorate into debate about what the proper definition of EA is (guess how many different “right answers” there are) or which of TOGAF® or Zachman or <insert your favourite framework here> is the (only) correct framework or why all of them are totally wrong, or worse still, what the correct interpretation of the minutiae of some aspect of framework X might be.

Perhaps the only comfort we can draw from the current lack of proper recognition of EA by the business is the fact that the Zachmanites are actually not firing bullets at the Rheinlanders (or some other tribe). Apart from the occasional character assassination, it’s all reasonably civilized. There’s just not enough to lose. But this sort of inward looking debate gets us nowhere.

I use TOGAF® . If you use another framework that’s better suited to your purpose, I don’t have a problem with that. I use it as framework to help me think. That’s what frameworks are for. A good framework doesn’t exclude the possibility that you use other guidance and insights to address areas it doesn’t cover. For example, I make a lot of use of the Business Model Canvas from Osterwalder and Pigneur and I draw ideas from folks like Tom Graves (who in turn has specialized the Business Model Canvas to EA). A framework (and any good methodology) is not a cookbook. If you understand what it tries to achieve, you can adapt it to fit each practical situation. You can leave the salt out. You can even leave the meat out! There are some reasonable criticisms of TOGAF® from within and outside The Open Group. But I can use TOGAF® with those in mind. And I do. One of the things I like about The Open Group is that it’s open to change – and always working on it. So the combination of The Open Group and TOGAF® and the awareness of important things coming from other directions provides me with an environment that, on the one hand, encourages rigour, and on the other, constantly challenges my assumptions.

It’s not unusual in my work that I liaise with other people officially called Enterprise Architects. Some of these folks think EA is only about IT. Some of them think it’s only about abstractions. I also work with Business Architects and Business Process Architects and Business Strategists and Requirements Engineers and….. I could go on for a very long time indeed. All of these people have definitions of their own scope and responsibilities, which overlap quite enough to allow not just for fundamentalism but also serious turf wars. Just as out there in the real world, the fundamentalists and those who define their identity by what they are not are the ones who start wars which everyone loses.

The good news is that just about enough of the time enough of these folks are happy to look at what we are all trying to achieve and who can bring what to the party and will work together to produce a result that justifies our existence. And every time that happens I learn new things – things that will make a me a better Enterprise Architect. So if I get noticeably irritated by the religious disputes and respond a bit unreasonably in web forum debates, I hope you’ll forgive me. I don’t like war.

By the way, credit for the “fundamentalism” analogy goes to my friend and former colleague, François Belanger. Thanks François.

Enterprise Architecture will be a major topic of discussion at The Open Group Conference, Austin, July 18-22. Join us for best practices and case studies on Enterprise Architecture, Cloud, Security and more, presented by preeminent thought leaders in the industry.

Stuart Boardman is a Senior Business Consultant with Getronics Consulting where he co-leads the Enterprise Architecture practice as well as the Cloud Computing solutions group. He is co-lead of The Open Group Cloud Computing Work Group’s Security for the Cloud and SOA project and a founding member of both The Open Group Cloud Computing Work Group and The Open Group SOA Work Group. Stuart is the author of publications by the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI. He is a frequent speaker at conferences on the topics of Cloud, SOA, and Identity.

4 Comments

Filed under Enterprise Architecture, TOGAF®

New Open Group Guide Shows Enterprise Architects How to Maximize SOA Business Value with TOGAF®

By Awel Dico, Bank of Montreal

Service Oriented Architecture (SOA) has promised many benefits for both IT and business. As a result, it has been widely adopted as an architectural style among both private business and government enterprises. Despite SOA’s popularity, however, relatively few of these enterprises are able to measure and demonstrate the value of SOA to their organization. What is the problem and why is it so hard to demonstrate that SOA can deliver the much needed business value it promises? In this post I will point out some root causes for this problem and highlight how The Open Group’s new guide, titled “Using TOGAF® to Define and Govern Service-Oriented Architectures,” can help organizations maximize their return on investment with SOA.

The main problem is rooted in the way SOA adoption is approached. In most cases, organizations approach SOA by limiting the scope to individual solution implementation projects – using it purely as a tool to group software functions into services described by some standard interface. As a result, each SOA implementation is disconnected and void of the larger business problem context. This creates disconnected, technology-focused SOA silos that are difficult to manage and govern. Reuse of services across business lines, arguably one of the main advantages of SOA, in turn becomes very limited if not impossible without increased cost of integration.

SOA calls for standard-based service infrastructure that requires big investment. I have seen many IT organizations struggle to establish a common SOA infrastructure, but fail to do so. The main reason for this failure is again the way SOA is approached in those organizations; limiting SOA’s scope to solution projects makes it hard for individual projects to justify the investment in service infrastructure. As a result they fall back to their tactical implementation which cannot be reused by other projects down the road.

The other culprit is that many organizations think SOA can be applied to all situations – failing to realize that there are cases when SOA is not a good approach at all. An SOA approach is not cheap, and trying to fit it to all situations results in an increased cost without any ROI.

Fortunately there’s a solution to this problem. The Open Group SOA Work Group recently developed a short guide on how to use TOGAF® to define and govern SOA. The guide’s main goal is to enable enterprises to deliver the expected business value from their SOA initiatives. What’s great about TOGAF® in helping organizations approach SOA is the fact that it’s an architecture-style, agnostic and flexible framework that can be customized to various enterprise needs, architectural scopes and styles. In a nutshell, the guide recommends the incorporation of SOA style in the EA framework through customization and enhancement of TOGAF® 9.

How does this solve the problem I pointed out above? Well, here’s how:

SOA, as an architectural style, becomes recognized as part of the organization’s overall Enterprise Architecture instead of leaving it linked to only individual projects. The guide advises the identification of SOA principles and establishment of supporting architectural capabilities at the preliminary phase of TOGAF®. It also recommends establishment of SOA governance and creating linkage to both IT and EA governance in the enterprise. These architecture capabilities lift the heavy weight from the solution projects and ensure that any SOA initiative delivers business value to the enterprise. This means SOA projects in the enterprise share a larger enterprise context and each project adds value to the whole enterprise business in an incremental, reusable fashion.

When TOGAF® is applied at the strategic level, then SOA concepts can be incorporated into the strategy by indentifying the business areas or segments in the enterprise that benefit from a SOA approach. Likewise, the strategy could point out the areas in which SOA is not adding any value to the business. This allows users to identify the expected key metrics from the start and focus their SOA investment on high value projects. This also makes sure that each smaller SOA project is initiated in the context of larger business objectives and as such, can add measurable business value.

In summary, this short and concise guide links all the moving parts (such as SOA principles, SOA governance, Reference Architectures, SOA maturity, SOA Meta-model, etc.) and I think it is a must-read for any enterprise architect using TOGAF® as their organization’s EA framework and SOA as an architectural style. If you are wondering how these architectural elements fit together, I recommend you look at the guide and customize or extend its key concepts to your own situation. If you read it carefully, you will understand why SOA projects must have larger enterprise business context and how this can be done by customizing TOGAF® to define and govern your own SOA initiatives.

To download the guide for free, please visit The Open Group’s online bookstore.

Awel Dico, Ph. D., is Enterprise Architect for the Bank of Montreal. He is currently working on enterprise integration architecture and establishing best practice styles and patterns for bank wide services integration.  In the past he has consulted on various projects and worked with many teams across the organization and worked on many architecture initiatives, some of which include: leading mid-tier service infrastructure architecture; developing enterprise SOA principles, guidelines and standards; Developing SOA Service Compliance process; developing and applying architectural patterns; researching technology and industry trends, and contributing to the development of bank’s Enterprise Reference Architecture blueprint. In addition, Dr. Dico currently co-chairs The Open Group SOA Work Group and The Open Group SOA/TOGAF Practical Guide Project. He also co-supervises PhD candidates at Addis Ababa University, Computer Science – in Software Engineering track. Dr. Dico is also a founder of Community College helping students in rural areas of Ethiopia.

2 Comments

Filed under Service Oriented Architecture

TOGAF® Certification Success: More than 7,000 individuals certified from over 50 countries

By Andrew Josey, The Open Group

Certification is a core competence of The Open Group and key to the successful rollout of our standards. TOGAF®, an Open Group standard, is the de facto global standard for Enterprise Architecture. The fast adoption of TOGAF 9 and demand for its certification program by architecture professionals and their employers is indicative of the value to be gained from trusted, globally accepted standards supported through certification.

As one of the team who developed TOGAF 9, I regularly track the statistics to monitor the take-up and adoption worldwide. Certifications within the TOGAF 9 program are currently growing at over one thousand individuals per quarter. As of June 3rd there were 7,200 individuals certified from more than 50 countries.

Of particular interest is to look at the countries adopting TOGAF. The top five includes the UK, The Netherlands, The USA, Australia and South Africa.

(Note 1: Data as of June 3rd 2011. Other countries outside the top 30 include (in order) Spain, Ireland, Austria, Malaysia, Kuwait, Jordan, Portugal, Russia, Costa Rica, Taiwan, Hungary, Oman, Nigeria, Botswana, Luxembourg, Indonesia, Sri Lanka, Egypt, Chile, Thailand, South Korea and Peru.)

There are 34 TOGAF 9 training partners worldwide and 37 accredited TOGAF 9 courses. More information on TOGAF 9 Certification, including the directory of Certified People and official accredited training course calendar, can be obtained from The Open Group website.

As part of the ongoing process of “Making Standards Work®”, we will be defining new certification standards and policy in the member meetings at The Open Group Conference, Austin, Texas (July 18-22, The Four Seasons Hotel). This will include the development of certification for the ArchiMate® standard and the addition of tools certification for TOGAF® Version 9.

If you are able to join us in Austin in July, I hope you will be able to also join us at the member meetings to work on building the next certification standards. If you are not yet a member then I hope you will attend the conference itself and network with the members to find out more and consider joining us at The Open Group.

Andrew Josey is Director of Standards within The Open Group, responsible for the Standards Process across the organization. Andrew leads the standards development activities within The Open Group Architecture Forum, including the development and maintenance of TOGAF® 9, and the TOGAF® 9 People certification program. He also chairs the Austin Group, the working group responsible for development and maintenance of the POSIX 1003.1 standard that forms the core volumes of the Single UNIX® Specification. He is the ISO project editor for ISO/IEC 9945 (POSIX). He is a member of the IEEE Computer Society’s Golden Core and is the IEEE P1003.1 chair and the IEEE PASC Functional chair of Interpretations. Andrew is based in the UK.

2 Comments

Filed under Enterprise Architecture, TOGAF®

The Open Group updates Enterprise Security Architecture, guidance and reference architecture for information security

By Jim Hietala, The Open Group

One of two key focus areas for The Open Group Security Forum is security architecture. The Security Forum has several ongoing projects in this area, including our TOGAF® and SABSA integration project, which will produce much needed guidance on how to use these frameworks together.

When the Network Application Consortium ceased operating a few years ago, The Open Group agreed to bring the intellectual property from the organization into our Security Forum, along with extending membership to the former NAC members. While the NAC did great work in information security, one publication from the NAC stood out as a highly valuable resource. This document, Enterprise Security Acrhitecture (ESA), A Framework and Template for Policy-Driven Security, was originally published by the NAC in 2004, and provided valuable guidance to IT architects and security architects. At the time it was first published, the ESA document filled a void in the IT security community by describing important information security functions, and how they related to each other in an overall enterprise security architecture. ESA was at the time unique in describing information security architectural concepts, and in providing examples in a reference architecture format.

The IT environment has changed significantly over the past several years since the original publication of the ESA document. Major changes that have affected information security architecture in this time include the increased usage of mobile computing devices, increased need to collaborate (and federation of identities among partner organizations), and changes in the threats and attacks.

Members of the Security Forum, having realized the need to revisit the document and update its guidance to address these changes, have significantly rewritten the document to provide new and revised guidance. Significant changes to the ESA document have been made in the areas of federated identity, mobile device security, designing for malice, and new categories of security controls including data loss prevention and virtualization security.

In keeping with the many changes to our industry, The Open Group Security Forum has now updated and published a significant revision to the Enterprise Security Architecture (O-ESA), which you can access and download (for free, minimal registration required) here; or purchase a hardcover edition here.

Our thanks to the many members of the Security Forum (and former NAC members) who contributed to this work, and in particular to Stefan Wahe who guided the revision, and to Gunnar Peterson, who managed the project and provided significant updates to the content.

Jim HietalaAn IT security industry veteran, Jim is Vice President of Security at The Open Group, where he is responsible for security programs and standards activities. He holds the CISSP and GSEC certifications. Jim is based in the U.S.

Comments Off

Filed under Security Architecture

Exploring Synergies between TOGAF® and Frameworx

By Andrew Josey, The Open Group

A joint team of The Open Group and the TM Forum has recently completed a technical report exploring the synergies and identifying integration points between the TM Forum Frameworx and TOGAF® specifications.

The results of this activity are now available as a 110-page technical report published by The Open Group and TM Forum, together with a Quick Reference Guide spreadsheet (available with the report).

The technical report focuses on mapping TOGAF® to the Frameworx: Business Process Framework (eTOM), Information Framework (SID) and Application Framework (TAM). The purpose of this mapping is to assess differences in their contents, complementary areas and the areas for application – with the TOGAF® Enterprise Continuum in mind.

Identified Synergies

A summary of the identified synergies is as follows:

  1. Immediate synergies have been identified between the TOGAF Architecture Development Method (ADM) phases Preliminary, A, B, C and the Common Systems Architecture of the Enterprise Continuum. This document addresses the TOGAF ADM phases from Preliminary to Phase C. The synergies between business services (formerly known as NGOSS contracts) and the Common Systems Architecture will be dealt with in a separate document.
  2. TOGAF® provides an Architecture Repository structure that can smoothly accommodate the mapping of TM Forum assets; this feature can be leveraged to identify and derive the added value of the content.
  3. TM Forum assets can be classified as either Industry Architectures or Common Systems Architecture in (TOGAF®) Enterprise Continuum language. TOGAF® provides a widely accepted methodology to leverage these architectures into the development of enterprise architecture.
  4. Professionals that use TM Forum assets will find templates and guidelines in TOGAF® that facilitate the transformation of such TM Forum assets into deliverables for a specific project/program.
  5. TOGAF concepts as defined in the TOGAF® Architecture Content Framework provide clear definitions as to what artifacts from TM Forum assets have to be developed in order to be consistent and comprehensive with an architecture construct.

The full report can be obtained from The Open Group and TM Forum websites. At The Open Group, you can download it here.

Andrew Josey is Director of Standards within The Open Group, responsible for the Standards Process across the organization. Andrew leads the standards development activities within The Open Group Architecture Forum, including the development and maintenance of TOGAF® 9, and the TOGAF® 9 People certification program. He also chairs the Austin Group, the working group responsible for development and maintenance of the POSIX 1003.1 standard that forms the core volumes of the Single UNIX® Specification. He is the ISO project editor for ISO/IEC 9945 (POSIX). He is a member of the IEEE Computer Society’s Golden Core and is the IEEE P1003.1 chair and the IEEE PASC Functional chair of Interpretations. Andrew is based in the UK.

1 Comment

Filed under Enterprise Architecture, TOGAF®

TOGAF® Camp London: a free unconference where rules are made to be broken

By Steve Nunn, The Open Group

TOGAF® Camp is one of the highlights of The Open Group Conference experience, in my opinion: a place where there are no rules that aren’t made to be broken, and where every voice counts. As we’re preparing to hold another TOGAF® Camp in London on May 11, it’s worth revisiting what one entails and the kinds of discussions we have had in past “unconferences.”

If you’ve read my previous post on what an unconference is, you know that there is no set discussion going into TOGAF® Camp; and indeed, any topic regarding Enterprise Architecture in general is welcomed. Previous discussions have revolved around evaluating TOGAF® usage in practice, including sharing experiences of such usage; and the use of  EA/TOGAF® as a transformative framework (how to go from EA as a stovepipe to architecture in transformative projects). A particularly popular and instructive session that I recall focused on how to introduce EA with an enterprise. The ability to share experiences in relatively small groups appears to catalyze all attendees into full participation.

When I run The Open Group’s TOGAF® Camps, I enjoy watching people really delve into topics such as these, and getting excited about sharing their own experiences and learning from others. It’s rewarding to know that people take away new or refined ideas from these sessions that they will apply inside their own enterprises. And you, too, can benefit — not just from attending the next one in London, but by also reading highlights of the discussions from ones in the past on a wiki accessible to all.

The TOGAF® Camp in London will take place at Central Hall Westminster on Storey’s Gate as part of The Open Group Conference, London, May 9-13. It will be held from 3:30 p.m. to 6 p.m. on Wednesday, May 11 during the afternoon track session, and is free and open to all — whether attending the rest of the conference or not. Find out more or register here, or in person. Join us for libations afterwards for the full unconference experience!

Steve Nunn is the COO of The Open Group and the CEO of the Association of Enterprise Architects. An attorney by training, Steve has been with The Open Group since 1993. He is a native of the U.K. and is based in the U.S.

Comments Off

Filed under Enterprise Architecture, TOGAF®