Tag Archives: The Open Group

Steve Nunn Takes Up the Reigns as New President and CEO of The Open Group

By The Open Group

The Open Group is delighted to announce that Steve Nunn has formally taken over as President and CEO following Allen Brown stepping down from that role at the end of October 2015.

After conducting a process to choose Allen Brown’s successor earlier this year, The Open Group Governing Board selected Steve for the role.  Steve has a distinguished career to date, previously the Chief Operating Officer (COO) of The Open Group and CEO of the Association of Enterprise Architects (AEA).

Steve joined The Open Group in 1993, spending the majority of his time as COO and General Counsel.  Steve was also appointed CEO of the AEA from 2010 until 2015.  He is a lawyer by training and has an L.L.B. (Honors) in Law with French and retains a current legal practicing certificate.  Having spent most of his life in the UK, Steve has lived in the San Francisco Bay Area since 2007.

Outside of work, Steve enjoys spending time with his family, walking, playing golf, 80s music, and is a lifelong West Ham United fan.

“It’s an amazing time at The Open Group.  Having recently attained over 500 memberships from organizations throughout the globe, The Open Group continues to move forward with tremendous momentum and opportunities to shape the standards that can help solve our members’ business problems.  I am honored to be helping to lead that process,” Steve Nunn commented.  “Allen has developed and grown the organization beyond all recognition in his time as CEO and I wish him the very best in his upcoming endeavors.”

Allen Brown, outgoing President and CEO of The Open Group added, “I ask that you join me in congratulating Steve Nunn as he steps into his new role as President and CEO.  Having worked with Steve closely for many years building a great organization, I know he has all the capabilities to lead The Open Group to further growth and achievements.”

By The Open GroupSteve Nunn and Allen Brown

Join the conversation @theopengroup

4 Comments

Filed under Allen Brown, Boundaryless Information Flow™, IT, President and CEO, Standards, Steve Nunn, The Open Group

The Open Group Edinburgh 2015 Highlights

By Loren K. Baynes, Director, Global Marketing Communications, The Open Group

On Monday October 19, Allen Brown, President and CEO of The Open Group, welcomed over 230 attendees from 26 countries to the Edinburgh International Conference Center located in the heart of historic Edinburgh, Scotland.

Allen kicked off the morning with an overview of company achievements and third quarter activities. The Open Group has over 500 member organizations in 42 countries, with the newest members coming from Peru and Zambia. Allen provided highlights of the many activities of our Forums and Work Groups. Too many to list, but white papers, guides, snapshots and standards have been published and continue to be in development. The newest Work Group is Digital Business Strategy and Customer Experience. The UDEF Work Group is now named O-DEF (Open – Data Element Framework) Work Group. The Real Time and Embedded Systems Forum is becoming more focused on critical systems and high assurance. Our members and staff have been very productive as always!

The morning plenary featured the theme “Architecting Business Transformation” with BAES Submarines. Speakers were Stephen Cole, CIO, BAE Systems Maritime Submarines; John Wilcock, Head of Operations Transformation, BAE Systems Submarine Solutions; Matthew Heard, Senior Operations Engineer, BAE Systems Maritime Submarines; and Paul Homan, Enterprise Architect, IBM. The presentation included a history of BAES Submarines and a ‘case study’ on using TOGAF® to help define BAE’s strategy for transforming their operations and production functions. The gentlemen all advocated the need to continue to drive change and transformation through the TOGAF principles. TOGAF has provided a structured, standardized approach to solving functional problems. TOGAF also ultimately allows organizations to document and measure their success along the way for meeting business objectives.

Following the keynotes, all presenters joined Allen for a panel consisting of an engaging Q&A with the audience.

By Loren K. Baynes, Director, Global Marketing CommunicationsPaul Homan, John Wilcock, Matthew Heard, Stephen Cole, Allen Brown

In the afternoon, the agenda offered several tracks on Risk, Dependability and Trusted Technology; EA and Business Transformation and Open Platform 3.0™.

One of the many sessions was “Building the Digital Enterprise – from Digital Disruption to Digital Experience” with Mark Skilton, Digital Expert, and Rob Mettler, Director of Digital Business, both with PA Consulting. The speakers discussed the new Work Group of The Open Group – Digital Business and Customer Experience, which is in the early stage of researching and developing a framework for the digital boom and new kind of ecosystem. The group examines how the channels from 15 years ago compare to today’s multi-device/channel work requiring a new thinking and process, while “always keeping in mind, customer behavior is key”.

The evening concluded with a networking Partner Pavilion (IT4IT™, The Open Group Open Platform™ and Enterprise Architecture) and a whisky tasting by the Scotch Whisky Heritage Centre.

Tuesday, October 20th began with another warm Open Group welcome by Allen Brown.

Allen and Ron Ashkenas, Senior Partner, Schaffer Consulting presented “A 20-year Perspective on the Boundaryless Organization and Boundaryless Information Flow™. The More Things Change, the More They Stay the Same”.

Ron shared his vision of how the book “The Boundaryless Organization” came to light and was published in 1995. He discussed his experiences working with Jack Welch to progress GE (General Electric). Their pondering included “can staff/teams be more nimble without boundaries and layers?”. After much discussion, the concept of ‘boundaryless’ was born. The book showed companies how to sweep away the artificial obstacles – such as hierarchy, turf, and geography – that get in the way of outstanding business performance. The presentation was a great retrospective of boundaryless and The Open Group. But they also explored the theme of ‘How does boundaryless fit today in light of the changing world?’. The vision of The Open Group is Boundaryless Information Flow.

Allen emphasized that “then standards were following the industry, now their leading the industry”. Boundaryless Information Flow does not mean no boundaries exist. Boundaryless means aspects are permeable to boundaries to enable business, yet not prohibit it.

During the next session, Allen announced the launch of the IT4IT™ Reference Architecture v2.0 Standard. Chris Davis, University of South Florida and Chair of The Open Group IT4IT™ Forum, provided a brief overview of IT4IT and the standard. The Open Group IT4IT Reference Architecture is a standard reference architecture and value chain-based operating model for managing the business of IT.

After the announcement, Mary Jarrett, IT4IT Manager, Shell, presented “Rationale for Adopting an Open Standard for Managing IT”. In her opening, she stated her presentation was an accountant’s view of IT4IT and the Shell journey. Mary’s soundbites included: “IT adds value to businesses and increases revenue and profits; ideas of IT are changing and we need to adapt; protect cyber back door as well as physical front door.”

The afternoon tracks consisted of IT4IT™, EA Practice & Professional Development, Open Platform 3.0™, and Architecture Methods and Techniques.

The evening concluded with a fantastic private function at the historic Edinburgh Castle. Bagpipes, local culinary offerings including haggis, and dancing were enjoyed by all!

By Loren K. Baynes, Director, Global Marketing Communications

Edinburgh Castle

On Wednesday and Thursday, work sessions and member meetings were held.

A special ‘thank you’ goes to our sponsors and exhibitors: BiZZdesign; Good e-Learning, HP, Scape, Van Haren Publishing and AEA.

Other content, photos and highlights can be found via #ogEDI on Twitter.  Select videos are on The Open Group YouTube channel. For full agenda and speakers, please visit The Open Group Edinburgh 2015.

By Loren K. Baynes, Director, Global Marketing CommunicationsLoren K. Baynes, Director, Global Marketing Communications, joined The Open Group in 2013 and spearheads corporate marketing initiatives, primarily the website, blog, media relations and social media. Loren has over 20 years experience in brand marketing and public relations and, prior to The Open Group, was with The Walt Disney Company for over 10 years. Loren holds a Bachelor of Business Administration from Texas A&M University. She is based in the US.

Comments Off on The Open Group Edinburgh 2015 Highlights

Filed under boundaryless information flow, Enterprise Architecture, IT, IT4IT, Open Platform 3.0, The Open Group, The Open Group Ediburgh 2015, TOGAF

Balancing Complexity and Continuous Improvements – A Case Study from the Automotive Industry

By The Open Group

Background

The automotive industry is currently facing massive challenges. For the past 30-40 years, automakers have faced stiff competition in the marketplace, as well as constant pressure to make more innovative and efficient vehicles while reducing the costs to manufacture them.

At the same time, current technological advances are making the industry—and the technology inside automobiles—increasingly complex. Digitalization is also affecting not only how automobiles work but is forcing changes in the manufacturing process and in how automakers run their businesses. With technology now touching nearly every part of the business and how it functions, the IT landscape for automakers is becoming a web of interconnected systems running both inside and outside of the business.

In addition, with computing systems becoming a more integral part of the systems that run vehicles, the lines between traditional IT functions and IT within cars themselves are beginning to blur. With trends such as Big Data and analytics, the Internet of Things and The Open Group Open Platform 3.0™ making cars, manufacturers, dealers and owners increasingly interconnected, automotive company IT departments are being forced to get involved in areas of the business, such as product development and maintenance, in ways they’ve never been before.

Between economic forces and technological change, automakers, like many businesses today, are facing massive upheaval and the need for major transformation in order to deal with levels of business complexity they’ve never seen before.

Company

These challenges are very real for the automotive company in this case study. In addition to general economic and technological change, the company has gone through a number of transitions that have created additional infrastructure issues for the company. Over the past two decades, the company was bought then sold and bought again, bringing in two new owners and technological systems. Between the company’s original legacy IT systems and the systems brought in by its subsequent owners, the company’s IT landscape had become extremely complicated. In addition, the company is in the process of extending its footprint in the burgeoning Chinese market, a step that requires the company to invest in additional infrastructure in order to take advantage of China’s growing economic wealth to speed sales.

Between the company’s existing systems, the need to grow into emerging markets and increased digitalization across the company and its products, the company was in need of new approach to its overall architecture.

Problem

Although the company started early on to utilize IT to make the information flows across the company value chain as effective as possible, the existing IT environment had grown organically as the company had changed owners. In order to prepare themselves for an increasingly digital business environment, the company needed to address the increasing complexity of its systems without adding more complexity and while designing systems that could scale and run for the long haul.

Previously, the company had begun to consider using an Enterprise Architecture approach to address its growing complexity. Although the company had a number of solutions architects on staff, they soon realized that they needed a more holistic approach that could address the entire enterprise, not just the individual solutions that made up that IT landscape.

In an industry where time to market is of outmost importance there will always be challenges in balancing short-term solutions with strategic investments. As such, the company initially decided to invest in an Enterprise Architecture capability with the objective of addressing internal complexities to better understand and eventually deal with them. Because TOGAF®, an Open Group standard was seen as the de-facto industry standard for Enterprise Architecture it was the natural choice for the company to create its architecture framework. The majority of the Enterprise and solution Architects at the company were then trained and certified in TOGAF 9. Subsequently, TOGAF was adopted by the architecture community in the IT organization.

Within the IT department, TOGAF provided an ontology for discussing IT issues, and it also provided a foundation for the Enterprise Architecture repository. However, it was seen within the organization primarily as an IT architecture concern, not a framework for transformational change. The EA team decided that in order to really benefit from TOGAF and address the complexity challenges throughout the enterprise, they would need to prove that TOGAF could be used to add value throughout the entire organization and influence how changes were delivered to the IT landscape, as well as prove the value of a structured approach to addressing internal issues.

In order to prove that TOGAF could help with its overall transformation, the team decided to put together a couple of pilot projects within different business areas to showcase the benefits of using a structured approach to change. Due to a need to fix how the company sourced product components, the team decided to first pilot a TOGAF-based approach for its procurement process, since it was widely viewed as one of the most complex areas of the business.

A New Procurement Platform

The initial pilot project was aimed at modernizing the company’s procurement landscape. Although procurement is normally a fairly straightforward process, in the automotive business the intricacies and variations within the product structure, combined with a desire to control logistic costs and material flows, represented a major challenge for the company. In short, to save costs, the company only wanted to buy things they would actually use in the vehicle manufacturing process—no more, no less.

Over the years the IT supporting the company’s procurement process had become very fragmented due to investments in various point solutions and different partnerships that had been established over time. In addition, some parts of the system had been closed down, all of which made the information flow, including all the systems integrations that had occurred along the way, very difficult to map. There were also several significant gaps in the IT support of the procurement process that severely limited the transparency and integrity of the process.

Solution

Using TOGAF as an architecture framework and method in conjunction with ArchiMate®, an Open Group standard, for modelling notations and Sparx Enterprise Architect (EA) as a modelling tool, the team set out to establish a roadmap for implementing a new procurement platform. The TOGAF Architecture Development Method (ADM) was used to establish the architecture vision, and the architecture development phases were completed outlining a target architecture and a subsequent roadmap. No major adaptions were made to the ADM but the sourcing process for the platform was run in parallel to putting together the ADM, requiring an iterative approach to be used

As part of the roadmap, the following ArchiMate views were developed:

  • Motivation views
  • Information structure views
  • Baseline and target business process views
  • Baseline and target business function views
  • Baseline and target application function views
  • Baseline and target application landscape views
  • Baseline and target application usage views
  • Baseline and target infrastructure landscape views
  • Baseline and target infrastructure usage views

Each view was created using Sparx EA configured to facilitate the ADM process and acting as the architecture repository.

The TOGAF ADM provided a structured approach for developing a roadmap whose results could be traced back to the original vision. Having a well-defined methodology with clear deliverables and an artifacts meta-model made the work focused, and both TOGAF and ArchiMate were relatively easy to get buy in for.

The challenges for the project were mainly in one area—aligning the architecture development with the IT solution sourcing process. Because the company wanted to identify sourcing solutions early to assess costs and initiate negotiation, that emphasis pushed the project into identifying solutions building blocks very early on. In most cases, the output from the ADM process could directly be used as input for sourcing commercial of solutions; however, in this case, sourcing soon took precedence over the architecture development process. Usually moving through the ADM phases A to E can be done within a couple of months but evaluating solutions and securing funding within this company proved to be much more difficult and time consuming.

Results

With a new procurement process roadmap in hand, the company has now begun to use the ADM to engage with and get Requests for Information (RFIs) from new suppliers. In addition, using TOGAF and ArchiMate to map the company’s procurement process and design an infrastructure roadmap helped to demystify what had been seen as an extremely complex procurement process. The project allowed the IT team to identify where the real complexities were in the process, many of which are at the component level rather than within the system itself. In addition, the company has been able to identify the areas that they need to prioritize as they begin their implementation process.

Observations

Initially TOGAF was seen as a silver bullet within the organization. However, companies must realize that the TOGAF methodology represents best practices, and there is still a need within any organization to have skilled, knowledgeable Enterprise Architects available and with the mandate to do the work.

As part of the project, the following benefits were provided by TOGAF:

  • Provided structure to the analysis
  • Ensured a holistic perspective for all domains
  • Kept the team focused on the outcome, definition, roadmap, etc.
  • Provided a good view into current and future data for the roadmap
  • Provided proven credibility for the analysis

ArchiMate added additional support by providing well-defined viewpoints, and Sparx EA is a cost effective modelling tool and repository that can easily be deployed to all stakeholder in an initiative.

However, within this particular organization, there were a number of challenges that need to be overcome, many of which can hinder the adoption of TOGAF. These challenges included:

  • Competing processes, methodologies and capabilities
  • Strong focus on solution design rather than architecture
  • Strong focus on project delivery tradition rather than managing programs and outcomes
  • Governance for solutions rather than architecture

Adopting Archimate proved to be more straightforward internally at this organization because it could be used to address immediate modelling needs but without requiring a coordinated approach around methodology and governance.

In cases such as this, it is probably best to sell the TOGAF and ArchiMate methodologies into the business organization as common sense solutions rather than as specific technology architecture methodologies. Although they may be presented as such to the EA community within the organization, it makes the decision process simpler not to oversell the technical solution, as it were, to the business, instead selling them the business benefits of the process.

Future

Currently the company is beginning to move through the implementation phase of their roadmap. In addition, individuals throughout the organization have begun to regularly use ArchiMate as a tool for modeling different business areas within the organization. In addition the tools and concepts of TOGAF have been put into use successfully in several initiatives. The timeframe however for formally implementing a more comprehensive Enterprise Architecture Framework throughout other parts of the organization has been slowed down due to the company’s current focus on the release of new models. This is cyclical within the company and once the immediate focus on product delivery weakens, the need for consolidation and simplification will become a priority once again.

As with most companies, the key to a implementing a successful Enterprise Architecture capability within this company will come down to establishing a more effective partnership between the IT organization and the business organizations that IT is supporting. As such, for projects such as this, early engagement is key, and the IT organization must position itself not only as a delivery organization but a business partner that provides investment advice and helps minimize business risk through improved processes and technology based business transformation (as is prescribed by methodologies such as TOGAF and ArchiMate). This requires a unified view of the company mission and its business objectives and associated approaches from IT. Project managers, business analysts and Enterprise Architects must have a common view as to how to approach engagements for them to succeed. Without buy-in throughout the organization, the tools will only be useful techniques used by individuals and their real potential may not be realized.

Comments Off on Balancing Complexity and Continuous Improvements – A Case Study from the Automotive Industry

Filed under ArchiMate®, big data, digital technologies, EA, IoT, Open Platform 3.0, The Open Group, TOGAF

IT4IT™ Reference Architecture Version 2.0, an Open Group Standard

By The Open Group

1 Title/Current Version

IT4IT™ Reference Architecture Version 2.0, an Open Group Standard

2 The Basics

The Open Group IT4IT Reference Architecture standard comprises a reference architecture and a value chain-based operating model for managing the business of IT.

The IT Value Chain

The IT Value Chain has four value streams supported by a reference architecture to drive efficiency and agility. The four value streams are:

  • Strategy to Portfolio
  • Request to Fulfill
  • Requirement to Deploy
  • Detect to Correct

Each IT Value Stream is centered on a key aspect of the service model, the essential data objects (information model), and functional components (functional model) that support it. Together, the four value streams play a vital role in helping IT control the service model as it advances through its lifecycle.

The IT4IT Reference Architecture

  • Provides prescriptive guidance on the specification of and interaction with a consistent service model backbone (common data model/context)
  • Supports real-world use-cases driven by the Digital Economy (e.g., Cloud-sourcing, Agile, DevOps, and service brokering)
  • Embraces and complements existing process frameworks and methodologies (e.g., ITIL®, CoBIT®, SAFe, and TOGAF®) by taking a data-focused implementation model perspective, essentially specifying an information model across the entire value chain

3 Summary

The IT4IT Reference Architecture standard consists of the value chain and a three-layer reference architecture. Level 1 is shown below.

By The Open GroupThe IT4IT Reference Architecture provides prescriptive, holistic guidance for the implementation of IT management capabilities for today’s digital enterprise. It is positioned as a peer to comparable reference architectures such as NRF/ARTS, TMF Framework (aka eTOM), ACORD, BIAN, and other such guidance.

Together, the four value streams play a vital role in helping IT control the service model as it advances through its lifecycle:

By The Open GroupThe Strategy to Portfolio (S2P) Value Stream:

  • Provides the strategy to balance and broker your portfolio
  • Provides a unified viewpoint across PMO, enterprise 
architecture, and service portfolio
  • Improves data quality for decision-making
  • Provides KPIs and roadmaps to improve business communication

The Requirement to Deploy (R2D) Value Stream:

  • Provides a framework for creating, modifying, or sourcing a service
  • Supports agile and traditional development methodologies
  • Enables visibility of the quality, utility, schedule, and cost of 
the services you deliver
  • Defines continuous integration and deployment control points

The Request to Fulfill (R2F) Value Stream:

  • Helps your IT organization transition to a service broker model
  • Presents a single catalog with items from multiple supplier 
catalogs
  • Efficiently manages subscriptions and total cost of service
  • Manages and measures fulfillments across multiple suppliers

The Detect to Correct (D2C) Value Stream:

  • Brings together IT service operations to enhance results and efficiency
  • Enables end-to-end visibility using a shared configuration model
  • Identifies issues before they affect users
  • Reduces the mean time to repair

4 Target Audience

The target audience for the standard consists of:

  • IT executives
  • IT process analysts
  • Architects tasked with “business of IT” questions
  • Development and operations managers
  • Consultants and trainers active in the IT industry

5 Scope

The Open Group IT4IT standard is focused on defining, sourcing, consuming, and managing IT services by looking holistically at the entire IT Value Chain. While existing frameworks and standards have placed their main emphasis on process, this standard is process-agnostic, focused instead on the data needed to manage a service through its lifecycle. It then describes the functional components (software) that are required to produce and consume the data. Once integrated together, a system of record fabric for IT management is created that ensures full visibility and traceability of the service from cradle to grave.

IT4IT is neutral with respect to development and delivery models. It is intended to support Agile as well as waterfall approaches, and lean Kanban process approaches as well as fully elaborated IT service management process models.

The IT4IT Reference Architecture relates to TOGAF®, ArchiMate®, and ITIL® as shown below:

By The Open Group6 Relevant Website

For further details on the IT4IT Reference Architecture standard, visit www.opengroup.org/IT4IT.

Comments Off on IT4IT™ Reference Architecture Version 2.0, an Open Group Standard

Filed under IT4IT, Standards, Value Chain

The Open Group Edinburgh—The State of Boundaryless Information Flow™ Today

By The Open Group

This year marks the 20th anniversary of the first version of TOGAF®, an Open Group standard, and the publication of “The Boundaryless Organization,” a book that defined how companies should think about creating more open, flexible and engaging organizations. We recently sat down with The Open Group President and CEO Allen Brown and Ron Ashkenas, Senior Partner at Schaffer Consulting and one of the authors of “The Boundaryless Organization,” to get a perspective on Boundaryless Information Flow™ and where the concept stands today. Brown and Ashkenas presented their perspectives on this topic at The Open Group Edinburgh event on Oct. 20.

In the early 1990s, former GE CEO Jack Welch challenged his team to create what he called a “boundaryless organization”—an organization where the barriers between employees, departments, customers and suppliers had been broken down. He also suggested that in the 21st Century, all organizations would need to move in this direction.

Based on the early experience of GE, and a number of other companies, the first book on the subject, “The Boundaryless Organization,” was published in 1995. This was the same year that The Open Group released the first version of the TOGAF® standard, which provided an architectural framework to help companies achieve interoperability by providing a structure for interconnecting legacy IT systems. Seven years later, The Open Group adopted the concept of Boundaryless Information Flow™—achieved through global interoperability in a secure, reliable and timely manner—as the ongoing vision and mission for the organization. According to Allen Brown, President and CEO of The Open Group, that vision has sustained The Open Group over the years and continues to do so as the technology industry faces unprecedented and rapid change.

Brown’s definition of Boundaryless Information Flowis rooted in the notion of permeability. Ron Ashkenas, a co-author of “The Boundaryless Organization” emphasizes that organizations still need boundaries—without some boundaries they would become “dis-organized.” But like the cells walls in the human body, those boundaries need to be sufficiently permeable so that information can easily flow back and forth in real time, without being distorted, fragmented or blocked.

In that context, Brown believes that learning to be boundaryless today is more important than ever for organizations, despite the fact that many of the boundaries that existed in 1995 no longer exist, and the technical ability to share information around the world will continue to evolve. What often holds organizations back however, says Ashkenas, are the social and cultural patterns within organizations, not the technology.

“We have a tendency to protect information in different parts of the organization,” says Ashkenas. “Different functions, locations, and business units want their own version of ‘the truth’ rather than being held accountable to a common standard. This problem becomes even more acute across companies in a globally connected ecosystem and world. So despite our technological capabilities, we still end up with different systems, different information available at different times. We don’t have the common true north. The need to be more boundaryless is still there.  In fact it’s greater now, even though we have the capability to do it.”

Although the technical capabilities for Boundaryless Information Flow are largely here, the larger issue is getting people to agree and collaborate on how to do things. As Ashkenas explains, “It’s not just the technical challenges, it’s also cultural challenges, and the two have to go hand-in-hand.”

What’s more, collaboration is not just an issue of getting individuals to change, but of making changes at much larger levels on a much larger scale. Not only are boundaries now blurring within organizations, they’re blurring between institutions and across global ecosystems, which may include anything from apps, devices and technologies to companies, countries and cultures.

Ashkenas says that’s where standards, such as those being created by The Open Group, can help make a difference.  He says, “Standards used to come after technology. Now they need to come before the changes and weave together some of the ecosystem partners. I think that’s one of the exciting new horizons for The Open Group and its members—they can make a fundamental difference in the next few years.”

Brown agrees. He says that there are two major forces currently facing how The Open Group will continue to shape the Boundaryless Information Flow vision. One is the need for standards to address the changing perspective needed of the IT function from an “inside-out” to “outside-in” model fueled by a combination of boundaryless thinking and the convergence of social, mobile, Cloud, the Internet of Things and Big Data. The other is the need to shift from IT strategies being derived from business strategies and reacting to the business agenda that leads to redundancy and latency in delivering new solutions. Instead, IT must shift to recognize technology as increasingly driving business opportunity and that IT must be managed as a business in its own right.

For example, twenty years ago a standard might lag behind a technology. Once companies no longer needed to compete on the technology, Brown says, they would standardize. With things like Open Platform 3.0™ and the need to manage the business of IT (IT4IT™) quickly changing the business landscape, now standards need to be at the forefront, along with technology development, so that companies have guidance on how to navigate a more boundaryless world while maintaining security and reliability.

“This is only going to get more and more exciting and more and more interesting,” Brown says.

How boundaryless are we?

Just how boundaryless are we today? Ashkenas says a lot has been accomplished in the past 20 years. Years ago, he says, people in most organizations would have thought that Boundaryless Information Flow was either not achievable or they would have shrugged their shoulders and ignored the concept. Today there’s a strong acceptance of the need for it. In fact, a recent survey of The Open Group members found that 65 percent of those surveyed believe boundarylessness as a positive thing within their organization. And while most organizations are making strides toward boundarylessness, only a minority–15 percent—of those surveyed felt that Boundaryless Information Flow was something that would be impossible to achieve in a large international organization such as theirs.

According to Brown and Ashkenas, the next horizon for many organizations will be to truly make information flow more accessible in real-time for all stakeholders. Ashkenas says in most organizations the information people need is not always available when people need it, whether this is due to different systems, cultural constraints or even time zones. The next step will be to provide managers real-time, anywhere access to all the information they need. IT can help play a bigger part in providing people a “one truth” view of information, he says.

Another critical—but potentially difficult—next step is to try to get people to agree on how to make boundarylessness work across ecosystems. Achieving this will be a challenge because ways of doing things—even standards development—will need to adapt to different cultures in order for them to ultimately work. What makes sense in the U.S. or Europe from a business standpoint may not make sense in China or India or Brazil, for example.

“What are the fundamentals that have to be accepted by everyone and where is there room for customization to local cultures?” asks Ashkenas. “Figuring out the difference between the two will be critical in the coming years.”

Brown and Ashkenas say that we can expect technical innovations to evolve at greater speed and with greater effectiveness in the coming years. This is another reason why Enterprise Architecture and standards development will be critical for helping organizations transform themselves and adapt as boundaries blur even more.

As Brown notes, the reason that the architecture discipline and standards such as TOGAF arose 20 years ago was exactly because organizations were beginning to move toward boundarylessness and they needed a way to figure out how to frame those environments and make them work together. Before then, when IT departments were implementing different siloed systems for different functions across organizations, they had no inkling that someday people might need to share that information across systems or departments, let alone organizations.

“It never crossed our minds that we’d need to add people or get information from disparate systems and put them together to make some sense. It wasn’t information, it was just data. The only way in any complex organization that you can start weaving this together and see how they join together is to have some sort of architecture, an overarching view of the enterprise. Complex organizations have that view and say ‘this is how that information comes together and this is how it’s going to be designed.’ We couldn’t have gotten there without Enterprise Architecture in large organizations,” he says.

In the end, the limitations to Boundaryless Information Flow will largely be organizational and cultural, not a question of technology. Technologically boundarylessness is largely achievable. The question for organizations, Brown says, is whether they’ll be able to adjust to the changes that technology brings.

“The limitations are in the organization and the culture. Can they make the change? Can they absorb it all? Can they adapt?” he says.

1 Comment

Filed under Uncategorized

The Open Group Edinburgh 2015: BAE Systems – Using TOGAF® for Operations Transformation

By The Open Group

When Matthew Heard first heard the term TOGAF®, not only did he have no idea what it was but he misspelled the name of the standard at first. It wasn’t until after searching Google for “TOGATH” that the real name for the architectural framework popped up and he got a sense for what it was, he says. And thus began a more than 15-month journey that has started Heard and his colleagues at BAE Systems, a British defense, aerospace and security systems provider, down a path to help transform the Operations function of the company’s Maritime Submarine division.

As is the case when any company looks to TOGAF, an Open Group standard, BAE’s Submarine division was in search of a structured way to help make organizational changes when they sought out the framework. According to Heard, a Senior Operations Engineer at BAE, the company’s needs were multifold. As a product manufacturer, BAE was in need of a way to prepare their systems to transition from their current product to the next generation. With a new product planned to go into production in the near future—one that would require higher technical demands and performance—the company first needed to set itself up to smoothly move into production for the higher demand product while still building the current product line.

In addition, the company wanted to make operational changes. After having surveyed 3,000 of their employees regarding what could be done to make people’s jobs easier and make the company a better place to work, the company had received 8,000 comments about how to create a better working environment. After winnowing those down to 800 separate problem statements that included ideas on how to improve things like safety, deliverables and the overall workplace, the team had many potential ideas and solutions, but no way to determine where to start.

“How do you structure things so that you don’t try to do everything at once and therefore don’t do anything because it’s too overwhelming?” Heard says. “We had a lot of change to make but we couldn’t quantify what it was and what order to do it in.”

As it happened, IBM’s Paul Homan had been doing some work on-site with BAE. When he heard that the company was looking to make some organizational changes, he suggested they look at an Enterprise Architecture framework, such as TOGAF. Although the company’s new head of transformation was familiar with the framework, there were no Enterprise Architects on staff, no TOGAF certified employees and no one else on staff had heard of the standard or of Enterprise Architecture, Heard says. Thus the mix-up the first time he tried to look it up online.

After downloading a copy of TOGAF® 9.1, Heard and his colleague John Wilcock began the task of going through the entire standard to determine if it would help them.

And then they did something very unusual.

“The first thing we did was, anything with more than three syllables, we crossed out with a black pen,” Heard says.

Why did they go through the text and black out entire sections as if it were a classified document riddled with redacted text?

According to Heard, since many of the terms used throughout the TOGAF standard are technology and IT-driven, they knew that they would need to “translate” the document to try to adapt it to their industry and make it understandable for their own internal audiences.

“It talked about ‘Enterprise Architecture,’” Heard said. “If we said that to a welder or pipe fitter, no one’s going to know what that means. I didn’t even know what it meant.”

As a recent university graduate with a background in Engineering Management, Heard says the IT terminology of TOGAF was completely foreign to him. But once they began taking out the IT-related language and began replacing it with terminology related to what submarine mechanics and people in operations would understand, they thought they might be able to better articulate the framework to others.

“We didn’t know whether we had gone so far away from the original intent or whether we were still on the right line,” Heard says.

Luckily, with Paul Homan on-site, they had someone who was familiar with TOGAF that they could go to for guidance. Homan encouraged them to continue on their path.

“For example, it might say something like ‘define the enterprise architecture vision,’” Heard says. “Well I just crossed out the word ‘architecture’ and turned the word ‘enterprise’ into ‘function’ so it said ‘define the functional vision.’ Well, I can do that. I can define what we want the function to look like and operate like and have the performance that we need. That becomes tangible. That’s when we went back to Paul and asked if we were on the right track or if we were just making it up. He said, ‘Carry on with what you’re doing.’”

As it turned out, after Heard and Wilcock had gone through the entire 900-page document, they had maintained the essence and principles of TOGAF while adapting it so that they could use the framework in the way that made the most sense to them and for BAE’s business needs. They adapted the methodology to what they needed it to do for them—which is exactly what the TOGAF ADM is meant to do anyway.

TOGAF was ultimately used to help define BAE’s strategy for transforming their operations and production functions. The project is currently at the stage where they are moving from defining a scope of projects to planning which projects to begin with. The team has scoped approximately 27 transformation projects that will take place over approximately three to five years.

Heard says that it was a fortuitous coincidence that Homan was there to suggest the framework since it ultimately provided exactly the guidance they needed. But Heard also believes that it was also fortuitous that no one was familiar with the standard beforehand and that they took the risk of translating it and adapting it for their own needs. He feels had they already been trained in TOGAF before they started their project, they would have spent more time trying to shoehorn the standard into what they needed instead of just adapting it from the start.

“That was the real learning there,” he says.

Now Heard says he finds himself using the framework on a daily basis for any project he has to tackle.

“It’s now become a routine go-to thing even if it’s a very small project or a piece of work. It’s very easy to understand how to get to an answer,” he says.

Heard says that by providing a structured, standardized approach to solving problems, TOGAF ultimately allows organizations to not only take a structured approach to transformational projects, but also to document and measure their success along the way, which is key for meeting business objectives.

“Standardization gives process to projects. If you follow the same approach you become more efficient. If there’s no standard, you can’t do that.”

Learn more about how BAE is using TOGAF® for Business Transformation at The Open Group Edinburgh, October 19-22, 2015

Join the conversation #ogEDI

By The Open GroupMatthew Heard attended the University of Birmingham from where he graduated with an MSc in Engineering Management in 2013. During his time at University Matthew worked as a Project Engineer for General Motors, focusing on the development of improvements in efficiency of the production line. Upon graduating Matthew joined BAE Systems-Maritime-Submarines looking for a new challenge and further experience of change and improvement programmes. Since Matthew joined BAE his predominant focus has been the delivery of Operational change initiatives. Matthew undertook a review and translation of the TOGAF principles and objectives to develop a unique strategy to deliver a program of change for the Operations Function, the outputs of which delivered the Operations Transformation Strategic Intent and Work Scopes. Going forward Matthew aims to continue developing and utilising the principles and objectives of TOGAF to aid other functions within BAE with their own future strategic developments, starting with the HR Transformation Work Scope.

By The Open GroupJohn Wilcock has worked within the Maritime Sector for the last 27 years. Starting as a shipwright apprentice, John has worked his way up through the organisation to his current position as Head of Manufacturing & Construction Strategy. Throughout his career John has gained a wide range of experiences, working on a diverse selection of Defence and Commercial projects, including Warship and Submarine platforms. During this time John has been instrumental in many change programmes and in his current role John is responsible for the development and delivery of the functional Transformation and Build Strategies. In order to develop the Operations Transformation Strategy John has worked alongside Matthew Heard to undertake a review and translation of the TOGAF principles and objectives to create a bespoke strategic intent and work scope. John continues to drive change and transformation through the TOGAF principles.

By The Open GroupPaul Homan

Enterprise Architect at IBM, CTO for Aerospace, Defence & Shipbuilding IBM UKI

Comments Off on The Open Group Edinburgh 2015: BAE Systems – Using TOGAF® for Operations Transformation

Filed under architecture, Enterprise Transformation, Standards, TOGAF, TOGAF®

Strategic Planning – Ideas to Delivery

By Martin Owen, CEO, Corso

Most organizations operate at a fast pace of change. Businesses are constantly evaluating market demands and enacting change to drive growth and develop a competitive edge.

These market demands come from a broad number of sources, and include economic changes, market trends, regulations, technology improvements and resource management. Knowing where the demands originated, whether they are important and if they are worth acting on can be difficult.

We look at how innovation, Enterprise Architecture and successful project delivery needs to be intertwined and traceable.

In the past, managing ideation to the delivery of innovation has not been done, or has been attempted in organizational silos, leading to disconnections. This in turn results in change not being implemented properly or a focus on the wrong type of change.

How Does an Organization Successfully Embrace Change?

Many companies start with campaigns and ideation. They run challenges and solicit ideas from within and outside of their walls. Ideas are then prioritized and evaluated. Sometimes prototypes are built and tested, but what happens next?

Many organizations turn to the blueprints or roadmaps generated by their enterprise architectures, IT architectures and or business process architectures for answers. They evaluate how a new idea and its supporting technology, such as SOA or enterprise-resource planning (ERP), fits into the broader architecture. They manage their technology portfolio by looking at their IT infrastructure needs.

Organizations often form program management boards to evaluate ideas, initiatives and their costs. In reality, these evaluations are based on lightweight business cases without the broader context. organizations don’t have a comprehensive understanding of what systems, processes and resources they have, what they are being used for, and how much they cost and the effects of regulations. Projects are delivered and viewed on a project-by-project basis without regard to the bigger picture. Enterprise, technology and process-related decisions are made within the flux of change and without access to the real knowledge contained within the organisation or in the market place. IT is often in the hot seat of this type of decision-making.

Challenges of IT Planning

IT planning takes place in reaction to and anticipation of these market demands and initiatives. There may be a need for a new CRM or accounting system, or new application for manufacturing or product development. While IT planning should be part of a broader enterprise architecture or market analysis, IT involvement in technology investments are often done close to the end of the strategic planning process and without proper access to enterprise or market data.

The following questions illustrate the competing demands found within the typical IT environment:

How can we manage the prioritization of business, architectural-and project-driven initiatives?

Stakeholders place a large number of both tactical and strategic requirements on IT. IT is required to offer different technology investment options, but is often constrained by a competition for resources.

How do we balance enterprise architecture’s role with IT portfolio management?

An enterprise architect provides a high-level view of the risks and benefits of a project and the alignment to future goals. It can illustrate the project complexities and the impact of change. Future state architectures and transition plans can be used to define investment portfolio content. At the same time, portfolio management provides a detailed perspective of development and implementation. Balancing these often-competing viewpoints can be tricky.

How well are application lifecycles being managed?

Application management requires a product/service/asset view over time. Well-managed application lifecycles demand a process of continuous releases, especially when time to market is key. The higher level view required by portfolio management provides a broader perspective of how all assets work together. Balancing application lifecycle demands against a broader portfolio framework can present an inherent conflict about priorities and a struggle for resources.

How do we manage the numerous and often conflicting governance requirements across the delivery process?

As many organizations move to small-team agile development, coordinating the various application development projects becomes more difficult. Managing the development process using waterfall methods can shorten schedules but can also increase the chance of errors and a disconnect with broader portfolio and enterprise goals.

How do we address different lifecycles and tribes in the organization?

Lifecycles such as innovation management, enterprise architecture, business process management and solution delivery are all necessary but are not harmonised across the enterprise. The connection among these lifecycles is important to the effective delivery of initiatives and understanding the impact of change.

The enterprise view, down through innovation management, portfolio management, application lifecycle management and agile development represent competing IT viewpoints that can come together using an ideas to delivery framework.

Agile Development and DevOps

A key component of the drive from ideas to delivery is how strategic planning and the delivery of software are related or more directly the relevance of Agile Enterprise Architecture to DevOps.

DevOps is a term that has been around since the end of the last decade, originating from the Agile development movement and is a fusion of “development” and “operations”. In more practical terms it integrates developers and operations teams in order to improve collaboration and productivity by automating infrastructure, workflows and continuously measuring application performance.

The drivers behind the approach are the competing needs to incorporate new products into production whilst maintaining 99.9% uptime to customers in an agile manner.

To understand further the increase in complexity we need to look at how new features and functions need to be applied to our delivery of software. The world of mobile apps, middleware and cloud deployment has reduced release cycles to weeks not months with an emphasis on delivering incremental change. Previously a business release would be every few months with a series of modules and hopefully still relevant to the business goals.

The shorter continuous delivery lifecycle will help organizations:

  • Achieve shorter releases by incremental delivery and delivering faster innovation.
  • Be more responsive to business needs by improved collaboration, better quality and more frequent releases.
  • Manage the number of applications impacted by business release by allowing local variants for a global business and continuous delivery within releases.

The Devops approach achieves this by providing an environment that:

  • Will minimize software delivery batch sizes to increase flexibility and enable continuous feedback as every team delivers features to production as they are completed.
  • Has the notion of projects replaced by release trains which minimizes batch waiting time to reduce lead times and waste.
  • Has a shift from central planning to decentralized execution with a pull philosophy thus minimizing batch transaction cost to improve efficiency.
  • Makes DevOps economically feasible through test virtualization, build automation, and automated release management as we prioritize and sequence batches to maximize business value and select the right batches, sequence them in the right order, guide the implementation, track execution and make planning adjustments to maximize business value.

By Martin Owen, CEO, CorsoFigure 1: DevOps lifecycle

Thus far we have only looked at the delivery aspects, so how does this approach integrate with an enterprise architecture view?

To understand this we need to look more closely at the strategic Planning Lifecycle. Figure 2 shows how the strategic planning lifecycle supports an ‘ideas to delivery’ framework.

By Martin Owen, CEO, Corso

Figure 2: The strategic planning lifecycle

You can see here, the high level relationship between the strategy and goals of an organization and the projects that deliver the change to meet these goals. The enterprise architecture provides the model to govern the delivery of projects in line with these goals.

However we must ensure that any model that is built must be just enough EA to provide the right level of analysis and this has been discussed in previous sections of this book regarding the use of Kanban to drive change. The Agile EA model is then one that can both provide enough analysis to plan which projects should be undertaken and then to ensure full architectural governance over the delivery. The last part of this is achieved by connecting to the tools used in the Agile space.

By Martin Owen, CEO, Corso

Figure 3: Detailed view of the strategic planning lifecycle

There are a number of tools that can be used within DevOps. One example is the IBM toolset, which uses open standards to link to other products within the overall lifecycle. This approach integrates the Agile enterprise architecture process with the Agile Development process and connects project delivery with effective governance of the project lifecycle and ensures that even if the software delivery process is agile the link to goals and associated business needs are met.

To achieve this goal a number of internal processes must interoperate and this is a significant challenge, but one that can be met by building an internal center of excellence and finding a solution by starting small and building a working environment.

The Strategic Planning Lifecycle Summary

The organization begins by revisiting its corporate vision and strategy. What things will differentiate the organization from its competitors in five years? What value propositions will it offer customers to create that differentiation? The organization can create a series of campaigns or challenges to solicit new ideas and requirements for its vision and strategy.

The ideas and requirements are rationalized into a value proposition that can be examined in more detail.

The company can look at what resources it needs to have on both the business side and the IT side to deliver the capabilities needed to realize the value propositions. For example, a superior customer experience might demand better internet interactions and new applications, processes, and infrastructure on which to run. Once the needs are understood, they are compared to what the organization already has. The transition planning determines how the gaps will be addressed.

An enterprise architecture is a living thing with a lifecycle of its own. Figure 3 shows the ongoing EA processes. With the strategy and transition plan in place, EA execution begins. The transition plan provides input to project prioritization and planning since those projects aligned with the transition plan are typically prioritized over those that do not align. This determines which projects are funded and entered into, or continue to the Devops stage. As the solutions are developed, enterprise architecture assets such as models, building blocks, rules, patterns, constraints and guidelines are used and followed. Where the standard assets aren’t suitable for a project, exceptions are requested from the governance board. These exceptions are tracked carefully. Where assets are frequently the subject of exception requests, they must be examined to see if they really are suitable for the organization.

If we’re not doing things the way we said we wanted them done, then we must ask if our target architectures are still correct. This helps keep the EA current and useful.

Periodic updates to the organization’s vision and strategy require a reassessment of the to-be state of the enterprise architecture. This typically results in another look at how the organization will differentiate itself in five years, what value propositions it will offer, the capabilities and resources needed, and so on. Then the transition plan is examined to see if it is still moving us in the right direction. If not, it is updated.

Figure 3, separates the organization’s strategy and vision, the enterprise architecture lifecycle components and the solution development & delivery. Some argue that the strategy and vision are part of the EA while others argue against this. Both views are valid since they simply depend on how you look at the process. If the CEO’s office is responsible for the vision and strategy and the reporting chain as responsible for its execution, then the separation of it from the EA makes sense. In practice, the top part of the reporting chain participates in the vision and strategy exercise and is encouraged to “own” it, at least from an execution perspective. In that case, it might be fair to consider it part of the EA. Or you can say it drives the EA. The categorization isn’t as important as understanding how the vision and strategy interacts with the EA, or the rest of the EA, however you see it.

Note that the overall goal here is to have traceability from our ideas and initiatives, all the way through to strategic delivery. This comes with clear feedback from delivery assets to the ideas and requirements that they were initiated from.

By Martin Owen, CEO, CorsoMartin Owen, CEO, Corso, has held executive and senior management and technical positions in IBM, Telelogic and Popkin. He has been instrumental in driving forward the product management of enterprise architecture, portfolio management and asset management tooling.

Martin is also active with industry standards bodies and was the driver behind the first business process-modelling notation (BPMN) standard.

Martin has led the ArchiMate® and UML mapping initiatives at The Open Group and is part of the capability based planning standards team.

Martin is responsible for strategy, products and direction at Corso.

3 Comments

Filed under Uncategorized