Category Archives: architecture

The Role of Enterprise Architecture in Platform 3.0 Transformation

By Stuart Macgregor, CEO, Real IRM and The Open Group South Africa

Our transition to the highly-connected realm of Platform 3.0 will radically disrupt the way that we approach Enterprise Architecture (EA).

The current architectures and methodologies will simply not hold up in the era of Platform 3.0 – characterised by the forces of big data, mobility, the Internet of Things, and social media colliding.

In the Platform 3.0 era, power shifts to the customer – as we choose from a range of services offered conveniently via digital channels. By embracing Platform 3.0, organisations can respond to newly-empowered customers. New entrants can scale at unprecedented rates, and incumbents can pivot business models rapidly, while entering and exiting new markets as opportunities emerge.

EA plays an essential role in making these possibilities a reality. EA infuses IT into the DNA of the business. No longer is it about ‘IT’ and ‘business’. Technology is absolutely integral to the entire business, and business leaders are quickly realising the fundamental truth that ‘if you can’t change the system, you can’t change the business’.

A new and exciting Platform 3.0 architectural reality is emerging. It’s composed of microservices and platforms that are combined in radical new ways to serve point-in-time needs – powering new-found business opportunities and revenue streams, dramatically transforming your organisation.

Platform 3.0 refers to radically different ways for the organisation to securely engage with partners, suppliers, and others in your value chain or ecosystem.”

Managing volatile change

But, while driven by an urgent need to transform, to become faster and more agile, large organisations are often constrained by legacy infrastructure.

With an EA-focused approach, organisations can take a step back, and design a set of architectures to manage the volatile change that’s inherent in today’s quickly-digitising industries. EA allows business systems in different departments to be united, creating what The Open Group (the vendor-neutral global IT standards and certifications consortium) aptly describes as a “boundaryless” flow of information throughout the organisation.

Platform 3.0 refers to radically different ways for the organisation to securely engage with partners, suppliers, and others in your value chain or ecosystem. For a retailer, stock suppliers could access real-time views of your inventory levels and automatically prepare new orders. Or a factory, for example, could allow downstream distributors a view of the production facility, to know when the latest batch run will be ready for collection.

In almost every industry, there are a number of new disruptors offering complementary service offerings to incumbent players (such as Fintech players in the Banking industry). To embrace partnerships, venture-capital opportunities, and acquisitions, organisations need extensible architectural platforms.

More and more transactions are moving between organisations via connected, instantaneous, automated platforms. We’re seeing the fulfilment of The Open Group vision of Boundaryless Information Flow™ between organisations and fuels greater efficiencies.

Architecting for an uncertain future

We need to architect for an uncertain future, resigning ourselves to not always knowing what will come next, but being prepared with an architectural approach that enables the discovery of next-generation digital business opportunities.

By exploring open standards, this transformation can be accelerated. The concept of ‘openness’ is at the very heart of Platform 3.0-based business transformation. As different business systems fall into and out of favour, you’ll want to benefit from new innovations by quickly unplugging one piece of the infrastructure, and plugging in a new piece.

Open standards allow us to evolve from our tired and traditional applications, to dynamic catalogues of microservices and APIs that spark continuous business evolution and renewal. Open standards help up to reach a state of radical simplicity with our architecture.

The old-world view of an application is transformed into new applications – volatile and continually morphing – combining sets of APIs that run microservices, and serve a particular business need at a particular point-in-time. These APIs and microservices will form the basis for whatever application we’d like to build on top of it.

Architects need to prepare themselves and their organisations for an uncertain future, where technology’s evolution and businesses’ changing demands are not clearly known. By starting with a clear understanding of the essential building blocks, and the frameworks to re-assemble these in new ways in the future, one can architect for the uncertain future lying in wait.

Platform 3.0 requires a shift towards “human-centered architectures”: where we start acknowledging that there’s no single version of the truth. Depending on one’s role and skill-set, and the level of detail they require, everyone will perceive the organisation’s structure and processes differently.

But ultimately, it’s not about the user, or the technology, or the architecture itself. The true value resides in the content, and not the applications that house, transmit or present that content. Human-centered architectural principles place the emphasis on the content, and the way in which different individuals (from inside or outside the organisation) need to use that content in their respective roles.

As the EA practice formalises intellectual capital in the form of business models and rules, we create an environment for machine learning and artificial intelligence to play an essential role in the future of the organisation. Many describe this as the future of Platform 3.0, perhaps even the beginning of Platform 4.0?

Where this will eventually lead us is both exciting and terrifying.

@theopengroup

by-stuart-macgregor-ceo-real-irm

Stuart Macgregor is the CEO, Real IRM Solutions and  The Open Group South Africa. Through his personal achievements, he has gained the reputation of an Enterprise Architecture and IT Governance specialist, both in South Africa and internationally.

Macgregor participated in the development of the Microsoft Enterprise Computing Roadmap in Seattle. He was then invited by John Zachman to Scottsdale, Arizona to present a paper on using the Zachman framework to implement ERP systems. In addition, Macgregor was selected as a member of both the SAP AG Global Customer Council for Knowledge Management, and of the panel that developed COBIT 3rd Edition Management Guidelines. He has also assisted a global Life Sciences manufacturer to define their IT Governance framework, a major financial institution to define their global, regional and local IT organizational designs and strategy. He was also selected as a core member of the team that developed the South African Breweries (SABMiller) plc global IT strategy.

Stuart, as the lead researcher, assisted the IT Governance Institute map CobiT 4.0 to TOGAF®, an Open Group standard. This mapping document was published by ISACA and The Open Group. He participated in the COBIT 5 development workshop held in London in 2010.

1 Comment

Filed under architecture, Boundaryless Information Flow™, digital business, EA, Enterprise Architecture, Future Technologies, Internet of Things, interoperability, Open Platform 3.0, Platform 3.0, Standards, The Open Group, Uncategorized

Ensuring Successful Enterprise Architecture by Following Kotter’s Eight Stage Journey

By Stuart Macgregor, CEO, Real IRM Solutions and The Open Group South Africa

These industry insights look at John Kotter’s eight stages of change management, and explore his timeless blueprint for effective change leadership. These change management principles can gel with an enterprise architecture (EA) roadmap to achieve business transformation.

The company’s EA practice is viewed as the engine room that powers the move towards transformation, and not the end-goal in itself. However, Kotter’s eight stages have a huge role to play in the development of an EA practice.

Stage 1 – Establishing urgency

The journey begins with breaking new ground, jolting people out of their comfort zones, and forcing them to deal with often uncomfortable realities. Change, in general, is something people tend to resist – and one of the first tasks for change agents is to overcome the powerful forces of tradition.

This stage requires executives to arrive at a brutally honest assessment of the company as it currently stands. It means exposing issues that may hinder growth and adaption in the future. It involves assessing the market realities, confronting macro, global forces – and identifying all the possible crises, barriers, sources of resistance, as well as potential opportunities.

Most importantly, it requires leaders and change agents to start removing the sources of complacency within the company. In other words, they must refute the reasons that some use to believe change isn’t necessary, or that the cost of change will be too great.

Establishing (or reinvigorating) the company’s EA practice is vital in making a successful start on the change journey.

EA rises to the fore as the primary toolset that will enable lasting positive change. It guides the company from a state of fragmented applications, organisational structures and processes – and builds an integrated and optimised environment.

In short, EA fuses the business model imperatives and the IT portfolio.

Establishing a sense of urgency among key stakeholders (a process that is triggered by the company CEO) makes the formation of change leadership structures possible. From an architectural perspective, these are bodies like business architecture governance committees, architecture review boards, and IT steering committees.

Without adequate governance, enterprise architecture will remain a theoretical concept that will fail to deliver any transformational business benefits. This, in fact, moves the process neatly on to stage two…

Stage 2 – Creating the guiding coalition

Kotter shows that a strong, core team (the “guiding coalition”) lies at the heart of any good change strategy. From there, the message of change radiates outwards to stakeholders throughout the broader company and its extended ecosystem.

Importantly, this coalition must possess people with one or more of the following characteristics:

  • Position of power… from executives, to line managers, to others with an influential stature in the enterprise, it is essential to enlist the support of decision-makers at an early stage.
  • Expertise… team members with diverse skill sets and points of view, and experience in many of the key areas of the enterprise.
  • Credibility… those involved in the coalition need to have strong reputations and the ability to sway the mindsets of others that are hesitant to buy in to the change strategy.
  • Leadership… it is essential for the team to include proven leaders who are capable of the kind of visionary, strategic thinking that the coalition will demand.

The team is pulled together by mutual trust, a shared vision for the future, and a passion to achieve these common goals. While at this stage the end-state of business transformation may not be in view, there is a shared recognition that the company needs to change the way it operates.

From an EA perspective, this guiding coalition sets the tone where EA starts to be viewed as a business entity of sorts. In a fully functioning EA practice, the company manages its ‘stock in trade’ (the corporate intellectual capital), and assembles the various components into EA products and services that address specific stakeholder requirements.

By starting to run the EA practice as if it was like a business in itself, even at these early stages, the coalition sets out on the right path – one that will eventually see the company formalising and packaging intellectual capital, and turning it into a corporate asset.

The business model will work if the various stakeholders within the company receive more value than their perceived cost of contribution. For example, HR may benefit from having a clear map of everyone’s role profile; internal audit may value the accurate view of weaknesses in the company’s internal processes. Something of a virtuous feedback loop develops.

Stage 3 – Developing a vision and strategy

In Kotter’s third stage – “developing a vision and strategy” – the guiding coalition sets to work on crafting the vision of change and transformation.

This typically runs as an iterative, sometimes even messy, process. Many different perspectives from the various stakeholders are considered, as different role-players provide a number of alternative ways to approach problems and reach goals.

As Kotter reiterates, this is a stage that encompasses both the head and the heart. It is a dynamic process that sees the value of strong teamwork rising to the fore – as the guiding coalition eventually settles on a unified approach..

A shared vision

Because of this complexity, the coalition can take weeks, even many months, to achieve a coordinated strategy for the future. Once established, a key contribution of the enterprise architecture (EA) practice is reducing the time taken to produce deliverables – such as the business capability map, for example.

Developing the vision requires the coalition spearhead a number of initial EA work-streams.

To begin with, a set of initial readiness assessments need to be conducted. These provide a clear barometer of where the organisation currently stands, in terms of the maturity and health of its existing EA practice, or its ability to easily embed a new EA framework. The assessments play a vital role in informing the vision for the future state.

Creating a library of definitions is an important early stage activity that ensures all the key stakeholders start from a common understanding of what EA, and a number of other important concepts and terminologies, really means.

Each of these needs to be considered across three dimensions: EA domains, the EA continuum and the EA architecture practice:

  • EA domains consist of business architecture, information architecture, data architecture, applications architecture, and technology architecture.
  • The EA continuum considers reference models at a group/enterprise level, an individual business or divisional level, as well as at product application and product focus level.
  • The EA architecture practice spans the areas of EA products and services, EA people, EA content (models, principles, standards, inventory, etc), as well as processes and tools.

Guiding principles are formulated across these three dimensions and serve as input to EA vision and strategy.

So, what exactly does the vision need to look like? While there is no singular approach to this, Kotter outlines a number of important characteristics inherent in any good vision that a guiding coalition composes.

He says it must be imaginable, desirable, feasible, focused, and flexible. Finally, it must be simple to communicate (something I will look at more closely in my next Industry Insight).

A guiding coalition

As the vision starts to crystallise, the coalition segments it into different work-streams – and assigns champions to each of these. Having individuals accountable for every aspect of the vision creates a strong sense of ownership, and ensures essential aspects are never overlooked.

It is only by following this thorough approach to developing the vision that the company can address its core system challenges at a root cause level, and overcome the well-worn situation of endless ‘quick fixes’.

It must be imaginable, desirable, feasible, focused, and flexible.

Too often, budget and time constraints force companies to address only the surface symptoms – by implementing disjointed, piecemeal improvements that fail to address the underlying issues, and serve to undermine the company’s EA practice.

These kinds of vicious cycles start circling throughout the organisation. As its structures become increasingly dependent on ad hoc quick fixes, they are continually weakened. In today’s competitive market environments, this is something that businesses can ill afford to let happen.

But, by following the vigorous approach to strategy and vision creation, the guiding coalition ultimately arrives at a strategic plan that describes how the business will transition, what the end-state will look like, and where investments, energy and focus need to be directed.

As everyone buys into the vision, change agents foster a better understanding of the ‘customer’ (internal stakeholders within the enterprise), the ‘products’ (the capabilities made possible by the EA practice), and how these products will be structured and packaged to address particular business needs.

Stage 4 – Communicating the vision

From the outset, the guiding coalition is responsible for communicating the EA vision to a nucleus group of stakeholders. As the EA practice develops momentum, the communication emanates outwards, to an increasingly broad group of stakeholders within the business.

Clearly, in this phase, timing is everything.

Over time, the EA practice evolves from its fledgling state, to greater levels of maturity. As this happens, the nature of the messages will change.

John Kotter (who advises on the eight stages of change management) says the communication needs to contain the following characteristics:

  • Simplicity (eliminating jargon and verbosity)
  • Metaphor-rich (pictures are worth a thousand words)
  • Multiple forums (leadership sessions, team meetings, newsletters, Intranets, etc)
  • Repetition (to reinforce the key messages and ensure they ‘sink in’)
  • Leadership by example (conduct from leadership that aligns with the communications and messaging)
  • Explaining apparent inconsistencies (address everything that seems counterintuitive or illogical, to avoid the communication being undermined)
  • Two-way communication (involving a feedback loop wherever possible greatly increases engagement and empowerment levels)

Put simply, the goal of this phase is to ensure the right staff are provided with the right information, at the right time – and empowered to work constructively within the new EA framework.

The advantages of formalising corporate intellectual property and establishing an EA practice need to be clearly articulated – at both an individual level and a company-wide level. If the EA vision is not clearly understood, people will very quickly disengage. They will revert to old habits and frameworks of working, and the timelines for the EA practice to start delivering business value will increase.

Too often, the coalition becomes overly enamoured with EA as a discipline – too ‘inwardly-focused’ – and forgets about the importance of communicating regularly with key stakeholders, business owners, and decision-makers across the organisation.

In fact, there is a continuum, ranging on the one end from the purist that “sits in an Ivory Tower” and becomes too academic and removed from the business, to the other end of the spectrum, with an EA practice experienced in the realities of the company, knows its challenges (eg, political, technical, legacy-related), and takes a pragmatic approach to EA.

The latter is the approach most likely to succeed in generating a sustainable and value-adding EA practice.

Over time, the EA practice evolves from its fledgling state to greater levels of maturity.

Here I use the analogy of running the EA practice like a business in itself: through delivering value to stakeholders one builds a relationship where people willingly engage with the EA practice. In this ideal scenario, positive word of mouth is created – which becomes one of the most valuable forms of internal communication.

Another very impactful form of communicating the vision is when the coalition exemplifies the behaviour it is seeking to establish in others, and ‘leads by example’. By becoming a role model, the coalition is more likely to succeed in its quest to develop new ways of working within the broader company.

Stage 5 – Empowering action

But communication alone is not enough. Ensuring the broad-based empowerment of people involves doing the following:

  • Teams need to understand the vision for business transformation and the EA value proposition that will enable it. Individuals must internalise this, consider what it means to them, and truly buy into the vision. They, in turn, will become ‘marketers’ of the company’s EA practice – articulating the vision to other stakeholders.
  • Teams need to receive quality, comprehensive training on the EA disciplines and activities as they relate to the individual’s particular function within the company. They must be empowered with the architecture content that allows them to start harvesting information.
  • From there, teams need to populate all of this existing content (such as business strategies, IT strategies, existing applications portfolios, etc) into an integrated EA repository, fully embedded in the organisation.
  • An EA methodology – such as TOGAF – is customised and tailored to the company. This means aligning the EA process with the systems development life cycle, strategic planning, corporate governance, and business process improvement, for example.
  • Any barriers, at any stage, need to be swiftly removed, so individuals are unleashed to work and to add value within the new framework.

Stage 6 – Generating short-term wins

Quick wins, even on a small scale, become the catalyst to building momentum in enterprise architecture.

By this point in the process of business transformation, the company has established and communicated the vision for change, and then begun the process of empowering the right teams to start executing on that vision.

Now, as it starts to package some of the early-phase model content, it becomes crucial for the fledgling enterprise architecture (EA) practice to generate some quick wins. Demonstrating tangible business value, even on a small scale, helps to maintain the interest of key stakeholders, and ensures the momentum doesn’t start to wane.

In fact, a virtuous cycle should begin to emerge: as the EA practice develops the operational capability to satisfy some business needs, stakeholders begin to recognise the business value. This leads to positive word-of-mouth being spread throughout the company, which in turn stimulates increased levels of demand from various quarters.

Ultimately, this demand translates into increased willingness to invest in the EA journey. With greater levels of buy-in, the EA practice’s operational capabilities continue to expand, and the cycle continues.

Stage 7 – Success breeds success

Short-term wins become the catalyst to building momentum in EA. John Kotter says these early successes are vital for a number of reasons, including the following:

  • Providing evidence that sacrifices are worth it: many staff within the coalition and other areas of the business have invested great time and energy in getting to this point.
  • Reward change agents with a pat on the back: adding business value is the biggest recognition of success.
  • Help fine-tune vision and strategies: insights learned from practically applying EA can be fed back into the strategic thinking.
  • Undermine cynics and self-serving resisters: tangible EA successes start to erode the credibility of naysayers.
  • Keep bosses on board: maintaining the support of line managers, executives, and other senior stakeholders happens naturally
  • Build momentum: more and more people are drawn into the developing EA practice, as people want to associate with a ‘success story’.

It goes without saying that these short-term wins need to be built on a sustainable and professional EA practice. The foundations must be strong – so the content can be easily accessed, and re-used for further process improvement in other areas of the business.

As the demand for business transformation increases, the EA practice needs to manage expectations and delivery. The EA team cannot take on ‘too much’ in the early stages, and be seen as the team that slows things down, or hampers innovation and change.

Essentially, the value that stakeholders derive from EA needs to continually exceed their perceived cost of contribution.

As the practice reaches out into the broader company, new opportunities emerge for specialists to contribute their unique insights. To keep the right people on the team, the company also needs to attend to human capital issues, like:

  • Ensuring key EA staff members have professional development paths and the opportunities to further their formal qualifications.
  • Providing mentoring (from within the organisation, or by pulling in outside mentors).
  • Performance management processes that ensure staff are accurately rewarded for their performance.

With the right team in place, the lead architect’s focus can shift from the everyday EA operations to higher-value activities. These include continually engaging with executives from across the business – to extend the scope of the EA practice and ensure it remains relevant and value-adding.

The value that stakeholders derive from EA needs to continually exceed their perceived cost of contribution.

The lead architect and the team can concentrate on understanding the potentially disruptive “nexus of forces” (cloud, mobility, big data and social), conducting impact assessments, scenario planning, and implementing new strategies.

The architecture team is then operating on all three levels – strategic, tactical and operational; and facilitating learning across the enterprise.

In this way, the chief architect and his EA team start to position themselves as trusted advisors and business partners to the company – becoming a crucial leadership support function. Ultimately, the true measure of the EA team’s worth is the extent to which the company engages with it, and the extent to which business transformation has been realised.

Stage 8 – Making it stick

Shifting from a state of architecture execution to architecture leadership is the next step in the EA journey.

Kotter’s final stage guides an organisation on the optimum ways that change can be embedded, anchored and matured. From an Enterprise Architecture (EA) perspective, these phases relate to the ‘professionalising’ of the EA practice.

Earlier, we looked at generating tangible “early wins” in the EA practice, and how they can echo throughout the organisation, as positive word-of-mouth spreads. The next step is to build on this momentum and to establish EA across every layer of processes, people, content, and tools, and products/services.

So, what are the hallmarks of a mature-state EA practice?

  • Entrenching the ethos of “running the EA practice like a business”… The foundation of the ‘business model’ includes five process areas: managing the business, enhancing market reputation, winning better business, delivering valued solutions, and growing the EA capability. In this way, resource allocation remains tightly synced with business need.
  • Innovation… EA essentially manages intellectual capital as an asset, translating tacit individual knowledge into organisational assets, in the form of models – which fuels constant innovation. Ideas are crowd-sourced from employees and partner ecosystems, and then analysed and prioritised according to business impact.
  • Strategic planning is dynamic and living… As intellectual capital becomes formalised as a corporate asset, the company can perform strategic planning at a higher level. This enables it to respond with agility to any changes in the external environment, as well as evolving business models within the company walls.
  • Business processes and capabilities become optimised… integrated business processes are naturally (willingly) enforced across the business. Process owners and system custodians focus on the right business capabilities and continually optimise processes.
  • Investment… The organisation targets its technology investment on IT assets that support identified and measurable business objectives, all within the framework of EA.

These fundamentals represent a shift from a state of “EA execution” to what can be referred to as “architecture leadership”.

In this state of advanced EA maturity, EA should also be repositioned and de-coupled from the IT department. Ideally, EA practice leaders should be moved to the office of the CEO, reporting to a function such as transformation management.

One of the most important facets of successfully transitioning from isolated early wins to EA leadership, which is embedded throughout the company, is ensuring key people are retained. The departure of important individuals can have catastrophic consequences at this stage – meaning EA never becomes entrenched.

For this reason, successful business leaders place a high emphasis on training, mentoring and further developing the EA teams. As ambitions soar, and people develop a passion for EA, industry bodies like The Open Group provide a useful outlet for this energy.

By contributing to the industry standards that are developed by The Open Group, individuals enjoy a greater sense of purpose – a tangible feeling that they are working on ‘something bigger’. Added to this, new opportunities open up, to develop their careers and networks.

For the company, this represents something of a win-win situation. By retaining these key specialists, it ensures the EA programme does not suffer interruptions or collapses.

As the success of the EA practice continues and the solution base expands, a virtuous cycle develops momentum: more and more ‘customers’ within the company start benefiting from EA, and more and more people are willing to invest in it.

The change process speeds up and becomes smoother; the ambit of EA broadens, and starts to influence every aspect of the business – including things like strategy planning, risk management, business transformation, and even mergers and acquisitions.

The essence of EA – that of managing complexity and change – is never forgotten. This new world requires new ways of thinking to address challenges and grab opportunities. Simply put, firms that continue to perpetuate old practices, will be left in the dust.

I’ll leave you with one of the pioneers of EA, John Zachman, who succinctly describes this essential fact:

“Increasing flexibility and reducing time to market… will only happen with responsible and intellectual investment, in developing and maintaining Enterprise Architecture, to deliver quality information, to produce a quality enterprise.”

By Stuart Macgregor, CEO, Real IRMStuart Macgregor is the CEO, Real IRM Solutions and  The Open Group South Africa. Through his personal achievements, he has gained the reputation of an Enterprise Architecture and IT Governance specialist, both in South Africa and internationally.

 

Macgregor participated in the development of the Microsoft Enterprise Computing Roadmap in Seattle. He was then invited by John Zachman to Scottsdale, Arizona to present a paper on using the Zachman framework to implement ERP systems. In addition, Macgregor was selected as a member of both the SAP AG Global Customer Council for Knowledge Management, and of the panel that developed COBIT 3rd Edition Management Guidelines. He has also assisted a global Life Sciences manufacturer to define their IT Governance framework, a major financial institution to define their global, regional and local IT organizational designs and strategy. He was also selected as a core member of the team that developed the South African Breweries (SABMiller) plc global IT strategy.

Stuart, as the lead researcher, assisted the IT Governance Institute map CobiT 4.0 to TOGAF®. This mapping document was published by ISACA and The Open Group. He participated in the COBIT 5 development workshop held in London in 2010.

1 Comment

Filed under architecture, Business Transformation, EA, Enterprise Architecture, Enterprise Transformation, Standards, The Open Group, TOGAF®, Uncategorized

The Open Group London 2016 to Take Place April 25-28

By The Open Group

The Open Group, the vendor-neutral IT consortium, is hosting an event in London, April 25-28. Following on from the San Francisco event earlier this year, The Open Group London 2016 will focus on how Enterprise Architecture is enabling organizations to build better systems through architecting for digital business strategies.

The event will be held at Central Hall Westminster and key speakers include:

  • Steve Nunn,  President & CEO, The Open Group
  • Gunnar Menzel, VP, Chief Architect Officer, Capgemini Infrastructure
  • Shawn Mullen, Cloud Security Architect, IBM
  • Nemanja Kostic, Head of Application Architecture, Zurich Insurance
  • Gururaj Anjan, Enterprise Architect, Tata Consultancy Services

Full details on the range of speakers can be found here.

Monday’s keynote session, including presentations from both vendors and end-user organizations, will look at IT4IT™ and managing the business of IT. It will address how CIOs can go beyond current process-based approaches and equip their teams with the right information and tools to support new ecosystem collaborations, completely automate end-to-end workflows, and provide the business with the controls to govern IT.

The first UK/European TOGAF® User Group meeting will also take place on April 27. Attendees will have the opportunity to network with industry peers, expand their knowledge and collaborate to bring a strong user community.  The inaugural TOGAF User Group meeting in San Francisco earlier this year was very productive and engaging.

The London event will cover key themes relating to The Open Group industry forums including Healthcare, IT4IT, Open Platform 3.0™, and Risk, Dependability & Trusted Technology. Additional topics of discussion at the three-day event will include:

  • EA & Government – the increasing awareness of EA and the growing adoption of TOGAF® in India. Plenary presentations include a focus on the e-Pragati initiative of the state of Andhra Pradesh
  • ArchiMate® – New features and practical use cases
  • The Open Business Data Lake a reference architecture that demonstrates how to leverage more internal and external data, how to be more agile in creating insights for business value and how to improve the productivity of actually delivering it

Registration for The Open Group London event is open now, available to members and non-members, and can be found here.

Get event updates via Twitter – @theopengroup #ogLON

Sponsors and exhibitors include: avolution, BiZZdesign, Good e-Learning, Hewlett Packard Enterprise (HPE), Troux by Planview, Association of Enterprise Architects (AEA), Orbus, Van Haren Publishing, itSMF UK

Comments Off on The Open Group London 2016 to Take Place April 25-28

Filed under ArchiMate, ArchiMate®, architecture, Association of Enterprise Architects, digital business, EA, enterprise architecture, Healthcare, Internet of Things, Interoperability, IT4IT, OTTF, Security Architecture, Standards, Steve Nunn, The Open Group, The Open Group London 2016, TOGAF®, Uncategorized

The New Generation IT Operating Model

By Yan Zhao, Ph.D, President, Chief Architect, ArchiTech Group LLC

  1. Introduction

The New Generation IT Operating Model is mostly associated with the current trend of service orientation. A service-oriented IT operating model should be based on service-oriented IT architecture. More precisely, a service-oriented IT operating model should be part of service-oriented IT architecture, also as a part of enterprise architecture. We know that models are what architecture creates, which include static models for the descriptions of components, structures and relationships; and dynamic models for the descriptions of operations and processes, where the dynamic models are built and operated on top of the static models. This new generation IT operating model is part of the “new paradigm” or “paradigm shift” in modern enterprise and IT, which should be part of enterprise architecture as well.

  1. Architecture and Service Oriented Architecture

First, I’d like to clarify the concept of Architecture and the Service Oriented Architecture in this context. The original definition of Architecture by Sir Henry Watton in The Elements of Architecture stated “In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight”. This definition is applicable to our context as well, where the position of architecture for IT is similar to the position of architecture for a building construction. The purpose of IT architecture is for the effective and efficient operations of IT. IT architecture should serve all its relevant audience and stakeholders, should be understandable by them via various views (commodity). The architectural products has to be solid and practicable for implementation (firmness), and it has to be well accepted and appreciated (delight) to be adopted and be effective in guiding IT operation.

The core of architecture is its vision, insight, concepts presented, and implementation guidance. It is a practical art, a result of creation, which is not a result of engineering or process in a mechanical manner, but it guides engineering process for implementation. IT is evolving to be a line of business by itself. Therefore, IT architecture is in a complex domain of people, systems, and culture; and in a constantly changing environment. It has the similar composition of enterprise architecture in this sense, with IT being one segment in an enterprise. For such architecture development, it is important to balance discipline and control with flexibility and freedom for organic growth, due to the limitation of human capability in predicting the changes and in handling complex matters.

The shared service domain is actually a sub-domain inside IT. We cannot expect all functions in IT should be shared. Similar, the Service Oriented IT Architecture is in a sub-domain of IT architecture. The necessity of making a function to be a service only when it has potential to be shared and reused by multiple service consumers. The following figures illustrate the shared service domain inside IT domain and the service oriented IT architecture inside IT architecture domain.

By Yan Zhao, Ph.D, ArchiTech Group LLC

 

Figure 1. The shared service sub-domain in IT and the service oriented IT architecture sub-domain in IT architecture

  1. IT Operating Model with Service Orientation

The “Plan/Build/Run” is a typical and simple IT operating model, which is still valid if we apply lifecycle with it, and have service orientation content being embedded into all its operating stages. The lifecycle presented in ITIL (Information Technology Infrastructure Library) can be considered as its extension from IT service management prospective. ITIL has five stages instead of three: Service Strategy (plan), Service Design (build), Service Transition, Service Operation (run), Continual Service Improvement. We are going to discuss later here on ITIL as an integral part that fit into the Plan/Build/Run model, which focus on IT service portfolio management and IT service management lifecycle. The Broker/Integrate/Orchestrate model is one of the possibilities inside the content of Plan/Build/Run model, while there are other possibilities as well. A plan is still necessary, no matter the plan is to build something new or to act as a broker, to build something in-sourcing or out-sourcing, by brokerage or by integration. Usually, there are diversified elements based on circumstances. It usually needs more than just orchestration to run it. All these could be part of the “IT Operating Model”. It is dangerous to just assemble what services/products available in market without a future vision and a plan for long-term evolution. For a business to survive in a longer term, it has to know its own needs instead of being framed by what is available in market. It needs to create its unique product/service roadmap and pipeline, and not to be controlled by others.

In order to provide effective and efficient IT support and reduce complexity and cost, IT is evolving to provide commodity services that enable the separation of business functions from common shareable IT services. To operate IT as a service, it opens a new line of business, as identified in Federal Infrastructure Optimization Initiative. The IT Operation Reference Model illustrated in Figure 2 is based on such considerations. It provides a holistic view on what involved in operating IT as a line of business. IT is becoming one business segment inside an enterprise with its own mission and goals to achieve instead of being only in a supporting role as before. This Reference Model can help to organize and consolidate organizational core capabilities and to provide a simple and cohesive view.

By Yan Zhao, Ph.D, ArchiTech Group LLCFigure 2. IT Operation Reference Model

  1. IT Operation Reference Model

The IT Operation Reference Model, illustrated in Figure 2, consists of four pillars: Plan, Build, Run, and Stakeholders. It is an extension to the Plan/Build/Run model, and is constructed with considerations in service orientation, modularity, simplicity, and communicability. It operates in a lifecycle as illustrated in Figure 3. Security, as illustrated in Figure 2, is not only a technical solution, but also an integral part across the board. A security life cycle and process should be designed and associated with each stage in an IT operation lifecycle, with starting from the planning stage. Also, governance should be applied across the complete IT operation lifecycle as well.

The Service Portfolio Management is part of IT Service Management (in Run pillar of Figure 2), which is addressed in ITIL V3. ITIL provides a best practice reference for IT service management and operation, with current enhancement (in V3) in service portfolio management. Applying ITIL within an IT Operating Model enhances IT Operation with a service lifecycle management discipline. However, the specific architectures, models, service design, and ITIL adoption for each IT operation have to be based on each individual case, and an operating model should be built accordingly.

Plan: IT still needs strategy and plan to run even in service oriented IT operation paradigm, where the business model, service model, cost/funding model, implementation model, and operating model suitable for service orientation should be incorporated accordingly. In another words, the difference is in the content. The plan for new generation IT operation should be driven by business domain requirements, e.g. the external and internal drivers, so that to support business improvement goals and objectives. Architectures should be created accordingly. Also, a performance measurement model should be created to provide measurement guidance. The plan should well consider adaptability to changes in both business requirements and technology advancement, and be maintained as a live document with continuous improvement along IT operation Lifecycle.

Build: Business requirements drive technology decisions; and at the meantime, the new technologies will inspire business envisions and provide various possibilities for business being operated in a more effective and efficient way. It’s true that the IT product ownership implies slow change due to the cost associated with. The resource sharing and operated by some specialized service providers enable faster change due to cost sharing in nature. Also, the performance from such service providers can be enhanced by competition. The implementation mechanisms should be flexible enough for new services and devices to plug-in or to update. However, not everything can be handed out to others to operate. Enterprise data are likely still being managed inside enterprise for security reasons, with enterprise internal stewardship and ownership, though it can participate in shared services internally and externally. In this reference model, services and systems to be built are described in layers: business services, application and data services, infrastructure services, and physical services.

Run: This includes IT system and service management and operation during continuous performance and change. The system operation management includes the management of IT service systems, system hardware and software, as well as networks and data centers, either in-sourcing or out-sourcing. It also includes the management of applications and data that are resided and running on these systems. For IT service management, ITIL is a handy best practice reference to start with.

Stakeholders: The stakeholders should be identified across the three pillars or the three operating stages in a lifecycle. Clearly roles and responsibilities should be identified, and be aligned with the operation structure. The operation model, structure, and architecture should be defined independent of individual stakeholder, so that people changes will not affect organization structure, process, and operation. Typically, the stakeholders can include business decision makers, resource owners, service providers, service consumers, governance and regulatory bodies, industry associations and standards groups, etc.

  1. The Relationship of the IT Operation Reference Model with ITIL

As a best practice reference, ITIL provides guidance on how to manage IT operation with service lifecycle. The relationship of ITIL Lifecycle with IT Operation Reference Model is illustrated in Figure 3. The IT service management lifecycle and its associated best practice reference based on ITIL v3 is the core for running an IT operation, as illustrated in the IT Operation Reference Model in Figure 2. The different focuses of the two can be summarized as:

  • Objective: The IT Operation Reference Model intends to provide a simple and cohesive view on IT operation domain structure, components and relationships; while ITIL focuses on providing guidance and reference details for IT service management and operation.
  • Components: The IT Operation Reference Model focuses on IT functional components; while ITIL focuses on IT operational components.
  • Structure: The IT Operation Reference Model is structured into categorized and layered components in each stage of IT operation; while ITIL is structured around IT service management and operation lifecycle to provide its associated best practice references.

In Figure 3, the middle section illustrates the relationships among the four pillars in the IT Operation Reference Model. The stakeholders play the central operating roles. They should be the driving force and active players in IT operation lifecycle. The stages of ITIL service lifecycle can be linked to the stages in Plan/Build/Run IT operation lifecycle. The lifecycles of both reflect iterative processes during IT operation. A well architected service lifecycle and management processes can maximize operational efficiency and productivity, as well as reduce the costs.

 

By Yan Zhao, Ph.D, ArchiTech Group LLCFigure 3. Apply ITIL to the IT Operating Model based on the IT Operation Reference Framework

In conclusion: A Service Oriented IT Operating Model should be rooted on a Service Oriented IT Architecture, which has to be custom built for each individual IT organization based on its service requirements, responsibilities, and operating environment, though best practice reference can be helpful. Each IT operation is forming an ecosystem of its own, which needs insight, creativity, and systematic discipline to figure out the best operating model and to clear the way for its execution.

By Yan Zhao, Ph.D, ArchiTech Group LLCDr. Yan Zhao, President, ArchiTech Group LLC, is an enterprise level chief architect, strategist, thought leader, and innovator; was also an executive for Fortune 500 companies and a professor. She has over 20 years work experience across academia, corporate research, software industry, and consulting service, where she demonstrated strength in insight, vision, creativity, and discipline. She is a positive thinker and a motivational leader with experience in leading R&D, capability and intellectual property development, and consulting practice. She received a Ph.D in computer science and a master in mathematics from Arizona State University, has 6 patents granted, 4 patents pending, a number of invention disclosures and publications.

yan.zhao@architechllc.com

@theopengroup

1 Comment

Filed under architecture, Enterprise Architecture, IT, Service Oriented Architecture, Uncategorized

TOGAF® User Group Meeting Preview: A Conversation with Terry Blevins

By The Open Group

The Open Group will be hosting its first TOGAF® User Group Meeting on January 25 in San Francisco. We recently spoke with long-time member, Terry Blevins, The Open Group Board Member, Fellow and former Chair of The Open Group Architecture Forum about his involvement over the years with TOGAF®, an Open Group standard.  We also discussed what users can look forward to at the User Group Meeting.

What’s your history with TOGAF? How long have you been a TOGAF user?

I’ve been involved with The Open Group since before it was The Open Group, when it was X/Open. I first engaged with The Open Group in the architecture area when they were working on the first or second release of TOGAF—that was around 1996. For a number of releases of TOGAF, I was a direct contributor. I was also a Co-chair of the Architecture Forum and chaired the Work Group covering certification of TOGAF architects for a couple years.

One of the main contributions I made to TOGAF was the Business Scenario Method, which is what I’ll be talking about in one of the breakout sessions at the User Group Meeting. For the past number of years, I’ve been on The Open Group Governing Board, so I haven’t participated directly in the Architecture Forum or its Work Groups, but I do keep my eye on things. Most recently I’ve been involved in the Healthcare Forum, with an eye on applying the disciple of architecture to improve healthcare information flow.

When you were a TOGAF contributor, what types of things were you contributing to the standard?

When I first contributed content ,I was working for NCR Corporation where we were keen on seeing standard approaches to architecture. The whole thing is that you bring contributions to the standard from your company or from your personal experience that are practical and that work. The Business Scenario Method was something that I created to help companies understand real, live business needs, and this is essential for any architecting project. Other contributions were spread throughout the early versions of the TOGAF specification.

Why a User Group Meeting now?

The growth of the number of people who are certified in TOGAF is huge. It’s truly become an accepted method worldwide and has resulted in pull from the business side of organizations. That pull and worldwide interest generates a need for people to come together and share. In addition, I think there is a greater occurrence of procurements for architects that are certified in TOGAF today. So that puts the importance in the user community on truly understanding how to apply TOGAF, which drives a need for a place where users can go. Another dimension is, of course, in reaching out to the user community to drive TOGAF with requirements that represent the users!

Those certified and/or using TOGAF have always had the Architecture Forum as a venue where they could share, but the Architecture Forum has become so big and so concentrated on the aspects of developing the method. Many in the TOGAF user community are not interested in developing methods; their interest is in the application of the method. They really want to have a forum to go to where they can talk to other users of TOGAF and talk about what works, what doesn’t work, share their stories and accomplishments and get some hints on how to avoid failures. It’s more about the application of TOGAF.

We’d always thought that there would be a point in time where it would be very difficult for the Architecture Forum to serve both the purpose of users and of people that were methodologists. We may have hit that point. Having a forum that is less formal, like a user group, is attractive to users. Then they can also gather requirements and send them off to the Architecture Forum and say ‘this is our collective voice on constructive improvement points for TOGAF. Do with them what you may.’

What can users expect from the User Group Meeting?

I tell people that we want the users to ‘SEE’ TOGAF differently, differently in comparison to reading the book, getting the training or taking tests. What I mean by ‘SEE’ is that we want users to be able to ‘share’ experiences, so that’s the ‘s’ part of ‘see.’ We want the users to get ‘enlightened’ on new things down the road and the current thinking on what might be next. And we also want users to feel that they’re ‘engaged’ in making improvements to TOGAF. We want to provide the users the ability to share their experiences, successes and failures, get information that they might not get in the books or the training and have the opportunity to say ‘Hey, this should change.’ So that’s SEE—Share, Enlightenment and Engagement.

You’re hosting the Using the Business Scenarios track – what can users look forward to in that track?

In the Business Scenario session, I wanted to make sure that we have some structure and an agenda. But if the structure breaks down because the users want to take the conversation someplace, we’ll let that happen. The structure was created to cover sharing, engagement and enlightenment—the users can change that if they want. If the structure holds, I’ll provide some background on what the Business Scenario method is, and we’ll ask for some stories about how the users get customer requirements, what challenges they have, special techniques they use and key successes and barriers. Then we’ll look at what needs to be done to make the Business Scenario Method better or what we can do to make capturing requirements easier and open up that conversation. Finally, we’ll talk about the latest thinking regarding Business Scenarios. There’s some changes I’ve recently made to the method, and I’ve also added some tips, tricks and techniques that I’ll share with the users. The focus will be on how people really get the business requirements they need to drive their architecting work.

What do you consider to be the primary benefits having a user meeting for TOGAF?

I hope the benefit is that they’re really learning from other users and learn what pitfalls to avoid. Their benefit is they’re getting the experience of other users, and that’s going to make them better architects. Secondly, they have a real opportunity to provide their voice on what needs to be done to make the tools better so they can have something in the future that will be better positioned to make them better architects. With active participation, the attendees are going to learn some things that will help them be better architects, which is going to make them more desirable and hopefully they’ll have better career opportunities.

What else do you hope users will get out of the User Group Meeting?

The pride in being able to say they are part of the larger community and an active participant in putting together a voice capable of moving the discipline of architecture forward.

How will the User Group Meeting help inform the evolution of the standard?

By gathering requirements. We’ve designed some TOGAF improvement suggestion index cards that we’ll pass out to users and ask them to fill out the cards whenever they come up with an idea for an improvement. We’ll ask them to turn those in, and, by the way, for each card they’ll get a raffle ticket, which will be fed into a downstream process to improve TOGAF. That engagement part of the event is being facilitated through these cards. We’ll collect the cards, do an analysis and then make recommendations to the Architecture Forum.

It’s the first go, so we hope it will inspire more events, more mechanisms to collect TOGAF requirements and greater sharing experiences. We also hope the user community will take an active role in shaping how these user group sessions may evolve.

For more information on The Open Group San Francisco 2016, please visit http://www.opengroup.org/sanfrancisco2016.

@theopengroup #ogSFO

 

Comments Off on TOGAF® User Group Meeting Preview: A Conversation with Terry Blevins

Filed under architecture, The Open Group, The Open Group San Francisco 2016, TOGAF®, 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®

In Praise Of Heuristics – or Saving TOGAF® From Its Friends

By Stuart Boardman, Senior Business Consultant, Business & IT Advisory, KPN Consulting and Ed Harrington, Senior Consulting Associate, Conexiam

As the world’s best known and most used Enterprise Architecture (EA) framework, it’s quite reasonable that TOGAF®, an Open Group standard, attracts criticism from both outside and within The Open Group membership. We would like to discuss a particular class of criticism and even more about the thinking behind that.

This criticism states that TOGAF is neither rigorous nor scientific and that any good EA framework should be both of those things. Now we don’t know anyone who wouldn’t agree that TOGAF could be more rigorous about some things and that’s one of the areas highlighted for attention in the next version of TOGAF.

But, “scientific”? There’s the rub. What do we mean by scientific?

Machines, Nature and Enterprises

What these critics promote is a method, which for any given enterprise, under identical conditions will always deliver the same, “correct” result – regardless who executes the method, as long as they follow the rules. This approach depends on a very 19th/20th Century mechanistic view of an enterprise.

We agree that an enterprise is a system. Mechanical systems behavior is generally predictable. If you get the equation right, you can predict the behavior under any given set of conditions with an accuracy of (to all intents and purposes) 100%. So, if an enterprise were a machine, you could come up with a method that meets this requirement.

Natural and environmental systems do not, in general, behave predictably (leaving trivia like Pavlov and his dogs out of it). There is room for discussion for any one system under consideration as to why this is. It could just be because there are so many variables that we can’t capture all of them at one instant in time (i.e. they are highly complex) or because the system is chaotic (i.e. extremely sensitive to initial conditions) or even stochastic (i.e. we can only establish a probability for a particular outcome) – or possibly a mixture of those things.

A major aspect of enterprises is that, to a considerable extent, they are made up of people, individually and in groups. Each with their shifting perceptions of what “good” is. In fact even a single organization behaves more like an organism than like a machine (note: we are not claiming that organizations are organisms).

Especially important is that enterprises function within wider ecosystems in which external factors like resource availability, innovation, competition, customer loyalty, legislation and regulation (to name but a few) constantly affect the behavior of the enterprise. To reliably predict the behavior of the enterprise we would need to know each and every factor that affects that behavior. Complexity is a major factor. Do we recognize any existing enterprises that do not conform to this (complex) model?

Science and Uncertainty

Enterprises are complex and, we would argue, even chaotic systems. Change the initial conditions and the behavior may be radically different (a totally different equation). A real scientific method for EA would then necessarily reflect that. It would deliver results, which could continue to adapt along with the enterprise. That requires more than just following a set of rules. There is no “equation”. There may be a number of “equations” to choose from. Some degree of experience, domain knowledge and empathy is required to select the most adaptable of those equations. If the world of software architecture hasn’t yet determined a formula for the perfect agile system, how can we imagine the even more complex EA domain could?[1] Any such method would be a meta-method. The actual method followed would be an adaptation (concretization/instantiation) of the meta-method for the system (i.e. enterprise) under examination in its then specific context.

So even if there is an EA method that delivers identical results independent of the user, the chances they’d be correct are…well, just that – chance. (You probably have a better chance of winning the lottery!). The danger of these “scientific” approaches is that we kid ourselves that the result must be right, because the method said so. If the objective were only to produce a moment in time “as-is” view of an enterprise and if you could produce that before everything changed again, then a mechanistic approach might work. But what would be the point?

What Really Bothers Us

Now if the problem here were restricted to the proponents of this “scientific” view, it wouldn’t matter too much, as they’re not especially influential, especially on a global scale. Our concern is that it appears TOGAF is treated by a considerably larger number of people as being exactly that kind of system. Some of the things we read by TOGAF-certified folk on, for example, LinkedIn or come across in practice are deeply disturbing. It seems that people think that the ADM is a recipe for making sausages and that mechanistically stepping through the crop circles will deliver a nicely formed sausage.

Why is this? No TOGAF expert we know thinks TOGAF is a linear, deterministic process. The thousands of TOGAF certified people have a tool that, as TOGAF, itself in chapter 2.10 states: “In all cases, it is expected that the architect will adapt and build on the TOGAF framework in order to define a tailored method that is integrated into the processes and organization structures of the enterprise”.

Is it perhaps an example of the need so many people have to think the whole world is predictable and controllable – an unholy fear of uncertainty? Such people seek comfort and the illusion of certainty in a set of rules. That would certainly fit with an outdated view of science. Or perhaps the problem is located less with the architects themselves than with management by spreadsheet and with project management methodologies that are more concerned with deadlines than with quality? Less experienced architects may feel obliged to go along with this and thus draw the wrong conclusions about TOGAF.

The Task of Enterprise Architecture

Understanding, accepting and taking advantage of the presence of uncertainty is essential for any organization today. This would be true even if it were only because of the accelerating rate of change. But more than that, we need to recognize that the way we do business is changing, that agile organizations encourage emergence[2] and that success means letting go of hard and fast rules. Enterprise architects, to be useful, have to work with this new model, not to be risk averse and to learn from (shared) experience. It’s our responsibility to help our enterprises achieve their strategic goals. If we turn our backs on reality, we may be able to tick off a task on a project plan but we’re not helping anyone.

A good EA framework helps us understand what we need to do and why we are doing it. It doesn’t do the thinking for us. All good EA frameworks are essentially heuristics. They assemble good practice from the experience of real practitioners and provide guidance to assist the intelligent architect in finding the best available solution – in the knowledge that it’s not perfect, that things can and will change and that the most valuable strategy is being able to cope with that change. TOGAF helps us do this.

[1] For more on complexity and uncertainty see Tom Graves’s SCAN method.

[2] See, for example Ruth Malan and Dana Bredemeyer’s The Art of Change: Fractal and Emergent

By Stuart Boardman, KPN, and Ed Harrington, ConexiumStuart Boardman is a Senior Business Consultant with KPN Consulting where he leads the Enterprise Architecture practice and consults to clients on Cloud Computing, Enterprise Mobility and The Internet of Everything. He is Co-Chair of The Open Group Open Platform 3.0™ Forum and was Co-Chair of the 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 KPN, the Information Security Platform (PvIB) in The Netherlands and of his previous employer, CGI as well as several Open Group white papers, guides and standards. He is a frequent speaker at conferences on the topics of Open Platform 3.0 and Identity.

Ed Harrington is a Senior Consulting Associate with Conexiam, a Calgary, Canada headquartered consultancy. He also heads his own consultancy, EPH Associates. Prior positions include Principle Consultant with Architecting the Enterprise where he provided TOGAF and other Enterprise Architecture (EA) discipline training and consultancy; EVP and COO for Model Driven Solutions, an EA, SOA and Model Driven Architecture Consulting and Software Development company; various positions for two UK based companies, Nexor and ICL and 18 years at General Electric in various marketing and financial management positions. Ed has been an active member of The Open Group since 2000 when the EMA became part of The Open Group and is past chair of various Open Group Forums (including past Vice Chair of the Architecture Forum). Ed is TOGAF® 9 certified.

4 Comments

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