Tag Archives: Enterprise Transformation

The Open Group London 2016 – Day Two Highlights

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

After a fantastic first day in Central Hall Westminster, The Open Group London 2016 continued on Tuesday, April 26 as attendees looked forward to another excellent line-up of speakers and topics. The Open Group President and CEO Steve Nunn welcomed the audience and announced that a day after launch, the IT4IT™ Certification Program already had over 50 certified people signed up. The certification is achieved by individuals who demonstrate knowledge and understanding of the IT4IT™ Reference Architecture, Version 2.0 standard.  Steve was then joined on stage by The Open Group CTO Dave Lounsbury, to discuss digital transformation and enabling digital business, with a focus on IT’s critical role in helping to achieve this.

Tuesday’s plenary sessions then got underway, with a highly entertaining presentation from Ron Tolido, Senior VP, Group CTO Office, Global Insights & Data Practice, CapGemini. Ron used numerous Game of Thrones references to explain how the open business data lake could be a blueprint for agile, data-driven businesses. He was quick to point out though that data ran the risk of appearing to a business in many elephant-themed guises; be it the “white elephant” driving up costs, the “Dumbo”, i.e. a fantasy, or the ”elephant in the room” than nobody wants to mention. To summarize, Ron, continuing his Game of Thrones-themed talk, argued that we need “burning [big data] platforms that are the pièce de résistance of Enterprise Architecture”.

By Loren K. Baynes, Director, Global Marketing Communications

Steve Nunn, Ron Tolido

It was then the turn of Sven van Wilpen, Business Architect, Fokker Industries, and Stuart Boardman, Enterprise Architect, Resilient EA, to discuss digitization in the aerospace industry and more specifically, the Fokker Factory. Coincidentally, elephants reared their collective trunks for the second time in the morning, when Stuart described the role of the architect as herding elephants.

One of the most interesting discussion points that emerged from this presentation was around change management, and it became clear that Fokker was putting some great process in place to support stakeholders who have to deal with the change. Not only that, but it needed to be made clear to them why change would make their lives better. Stuart also talked about implementing the right kind of change, highlighting the fact that when you make a process digital, it works differently. Don’t just digitize that manual process, but change the process itself.

After the coffee break, Steve Nunn made a presentation to Serge Thorn with HSBC, in recognition of his tireless work on The Open Group Architecture Forum TOGAF Localization Committee.  TOGAF® is an Open Group standard.

By Loren K. Baynes, Director, Global Marketing Communications

Serge Thorn, Steve Nunn

At this point, Steve handed the reins over to Wipro’s Chief Enterprise Architect & Head of Academy of EA, Pallab Saha for the rest of the morning session, to talk first about the relevance of Enterprise Architecture for India, and then about how it is helping to turn aspiration into inspiration to make digital government a reality.

Pallab talked in great detail about the e-Pragati project, which was designed to bring all government services under one roof to illustrate this. He described it as a new paradigm in governance, based on a whole-of-government framework that transcends departmental boundaries. Helpfully, Pallab also showcased a great video that explained the initiative in more detail and it is interesting to note that this regional project is being championed as best practice for other provinces in India.

The afternoon saw the conversations split into separate tracks, focused on Healthcare, Open Platform 3.0™, ArchiMate®, and a series of TOGAF® 9 tutorials, including:

  • History of The Open Group Healthcare Forum, Jason Lee, Director, Healthcare Forum, The Open Group
  • Architecting Customer Experience: Driving Transformative Digital Business, Trishit Baran Sengupta, Enterprise Architect, Wipro
  • Using TOGAF®, ArchiMate® and Open FAIR for Business Driven InfoSec, Thorbjørn Ellefsen, Managing Business Analyst, Capgemini
  • Creating an EA for Genesis Housing Association, Michelle Supper, Enterprise and System Architect, Science Inspired Ltd

The second day of the London event concluded with a networking dinner at Emirates Stadium – home of the Arsenal Football Club. In addition to a private tour of the stadium, guests enjoyed live music and a scrumptious dinner.  Allen Brown, former CEO of The Open Group, was announced as a Fellow, an honor bestowed upon only a select few for their immense dedication and body of work at The Open Group.

By Loren K. Baynes, Director, Global Marketing Communications

@theopengroup #ogLON

By Loren K. Baynes, Director, Global Marketing Communications

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

 

 

Leave a comment

Filed under Boundaryless Information Flow™, Cloud, Data Lake, Digital Transformation, EA, Enterprise Transformation, interoperability, IoT, open platform 3.0, Standards, Steve Nunn, The Open Group London 2016, TOGAF®, 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 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

The Open Group San Francisco 2016 Day One Highlights

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

On Monday, January 25, The Open Group kicked off its first event of 2016, focused on Enabling Boundaryless Information Flow™, at the Marriott Union Square in the city by the bay, San Francisco, California.

President and CEO Steve Nunn gave a warm welcome to over 250 attendees from 18 countries, including Botswana, China and The Netherlands. He introduced the morning’s plenary, which centered on Digital Business and the Customer Experience. This year also marks a major milestone for The Open Group, which is celebrating its 20th anniversary in 2016.

The Open Group Director of Interoperability Dr. Chris Harding kicked off the morning’s event speaking on “Doing Digital Business.”

Digital technology is transforming business today. As such, how Enterprise Architects can architect for and deliver better customer experience is a more critical factor for businesses today than ever before. For thousands of years, most business transactions happened face-to-face with human interaction at the heart of them. The Internet has changed that, largely taking humans out of the equation in favor of “intelligent” programs that provide customer service. As Enterprise Architects, the challenge now is to create corporate systems and personas that mimic human interaction to provide better service levels. To achieve that, Harding says, currently companies are looking at a number of improved models including providing microservices, Cloud architectures and data lakes.

To better enable the transformation toward digital customer experiences, The Open Group Open Platform 3.0™ Forum is currently working on an interoperability standard to support a variety of services that run on digital platforms. In addition, the Digital Business and Customer Experience Work Group—a joint work group of Open Platform 3.0 and the Architecture Forums—is currently working on customer-based architectures, as well as a whitepaper geared toward enabling better customer experiences for digital business.

In the second session of the morning, Mark Skilton of PA Consulting addressed the issue of “The Battle for Owning the Digital Spaces”. Skilton says that in this era of unprecedented digital information, we need to better understand all of that information in order to create business opportunities—however, much of that information is contained in the “gray” spaces in between interactions. Accessing that kind of data provides opportunities for businesses to get a better handle on how to provide digital experiences that will draw customers. It also requires “ecosystem” thinking where what is happening on both the micro and macro levels should be considered.

As such, companies must reconsider what it means to be an enterprise, platform or even a service. This requires a new way of looking at architectures that combines both physical and virtual environments to take advantage of those “gray” spaces in people’s lives. By interconnecting or “flattening” out people’s experiences, such as their work, living, commercial or social spaces, they will be allowed to take their digital experiences with them throughout their lives. To enable these things moving forward, architects will need to change their mindsets to think differently and consider experience more rather than just architectures. Behavior, interactivity, psychology, usability—the human factors—of advanced customer experience will need to be considered in the architecture development process more to create more connected spaces to meet people’s needs.

Trevor Cheung, Vice President Strategy & Architecture Practice for Huawei Global Services, spoke next on “Architecting for Customer Experience.” Cheung introduced the concept of the ROADS Experience, a principle for designing customer-driven architectures. According to Cheung, ROADS (Real-time, On-demand, All-online, DIY and Social) is critical for companies that want to become digital service providers. As organizations digitalize, they should think more holistically about customer experiences—including both internal (employees) and external audiences (customers, partners, etc.)—moving from an inside-out IT perspective to one that also considers outside-in constituencies.

For example, to provide omni-channel experiences, business architectures must focus on the values of stakeholders across the ecosystem—from buyers and their interests, to partners and suppliers or operations. By applying the ROADS principle, each stakeholder, or persona, can be considered along the way to develop an architecture blue print that covers all channels and experiences, mapping the needs back to the technologies needed to provide specific capabilities. Currently two whitepapers are being developed in the Digital Business and Customer Experience Work Group that explore these issues, including a new reference model for customer architectures.

In the last morning session Jeff Matthews, Director of Venture Strategy and Research, Space Frontier Foundation, presented “The Journey to Mars is Powered by Data: Enabling Boundaryless Information Flow™ within NASA.” Currently, NASA’s programs, particularly its endeavors to send people to Mars, are being enabled by complex Enterprise Architectures that govern each of the agency’s projects.

According to Matthews, nothing goes through NASA’s planning without touching Enterprise Architecture. Although the agency has a relatively mature architecture, they are continually working to breakdown silos within the agency to make their architectures more boundaryless.

Ideally, NASA believes, removing boundaries will give them better access to the data they need, allowing the agency to evolve to a more modular architecture. In addition, they are looking at a new decision-making operating model that will help them grapple with the need to buy technologies and setting up architectures now for programs that are being planned for 10-30 years in the future. To help them do this, Matthews encouraged audience members and vendors to reach out to him to talk about architectural strategies.

In addition to the event proceedings, The Open Group also hosted the inaugural meeting of the TOGAF® User Group on Monday. Aimed at bringing together TOGAF users and stakeholders in order to share information, best practices and learning, the day-long meeting featured topics relative to how to better use TOGAF in practicality. Attendees participated in a number of breakout sessions regarding the standard, intended to provide opportunities to share experiences and enlighten others on how to best use TOGAF as well as provide suggestions as to how the standard can be improved upon in the future.

Allen Brown, current interim CEO of the Association of Enterprise Architects (AEA), and former CEO of The Open Group, also introduced the AEA Open Badges Program for Professional Development. Much like badge programs for the Boy or Girl Scouts, the Open Badge program lets people demonstrate their professional achievements via digital badges that provide credentials for skills or achievements learned. Moving forward, the AEA will be providing digital badges, each of which will include embedded information showing the information learned to earn the badge. Attendees can earn badges for attending this conference. For more information, email OpenBadges@GlobalAEA.org.

Monday’s afternoon tracks were split into two tracks centered on Open Platform 3.0™ and Risk, Dependability and Trusted Technology. The Open Platform 3.0 track continued in the same vein as the morning’s sessions looking at how Enterprise Architectures must adapt to the changes due to digitalization and growing customer expectations. Accenture Enterprise Architect Syed Husain gave an insightful presentation on enabling contextual architectures and increased personalization using artificial intelligence. As both consumers and technology become increasingly sophisticated, demands for individualized preferences tailored to individuals are growing. Companies that want to keep up will need to take these demands into account as they evolve their infrastructures. In the Security track, sessions centered on privacy governance, best practices for adopting the Open FAIR Risk Management standard and dealing with cyber security risks as well as how to navigate the matrix of data classification to maximize data protection practices.

Concluding the day was an evening reception where event and TOGAF User Group attendees mixed, mingled and networked. The reception featured The Open Group Partner Pavilion, as well as short presentations from The Open Group Architecture, IT4IT™ and Open Platform 3.0 Forums.

@theopengroup #ogSFO

By Loren K. BaynesLoren 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 San Francisco 2016 Day One Highlights

Filed under Boundaryless Information Flow™, Cloud, EA, Enterprise Architecture, Internet of Things, Interoperability, IoT, Open Platform 3.0, Standards, Steve Nunn, The Open Group, The Open Group, The Open Group San Francisco 2016, The Open Group San Franscisco 2016, TOGAF®, Uncategorized

The Open Group to Hold Next Event in San Francisco

The Open Group, the vendor-neutral IT consortium, is hosting its next event in San Francisco January 25-28. The Open Group San Francisco 2016 will focus on how Enterprise Architecture is empowering companies to build better systems by architecting for digital business strategies. The event will go into depth on this topic through various individual sessions and keynotes.

Some of the many topics of discussion at the event include Business Architecture; how to architect systems using tools and frameworks such as TOGAF® and ArchiMate® (both Open Group standards); Social, Mobile, Analytics and Cloud (SMAC); Risk Management and Cybersecurity; Business Transformation; Professional Development, and improving the security and dependability of IT, including the global supply chain on which they rely.

Key speakers at the event, taking place at San Francisco’s Marriott Union Square, include:

  • Steve Nunn,  President & CEO, The Open Group
  • Trevor Cheung, VP Strategy and Architecture Practice, Huawei Global Services
  • Jeff Matthews, Director of Venture Strategy and Research, Space Frontier Foundation
  • Ajit Gaddam, Chief Security Architect, Visa
  • Eric Cohen, Chief Enterprise Architect, Thales
  • Heather Kreger, Distinguished Engineer, CTO International Standards, IBM

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

There will also be the inaugural TOGAF® User Group meeting taking place on January 25. Facilitated breakout sessions will bring together key stakeholders and users to share best practices, information and learn from each other.

Other subject areas at the three day event will include:

  • Open Platform 3.0™ – The Customer Experience and Digital Business
  • IT4IT – Managing the Business of IT. Case study presentations and a vendor panel to discuss the release of The Open Group IT4IT Reference Architecture Version 2.0 standard
    • Plus deep dive presentations into the four streams of the IT Value Chain along with the latest information on the IT4IT training and certification program.
  • EA & Business Transformation – Understand what role EA, as currently practiced, plays in Business Transformation, especially transformations driven by emerging and disruptive technologies.
  • Risk, Dependability & Trusted Technology – The cybersecurity connection – securing the global supply chain.
  • Enabling Healthcare
  • TOGAF® 9 and ArchiMate® – Case studies and the harmonization of the standards.
  • Understand how to develop better interoperability & communication across organizational boundaries and pursue global standards for Enterprise Architecture that are highly relevant to all industries.

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

Join the conversation @theopengroup #ogSFO

Comments Off on The Open Group to Hold Next Event in San Francisco

Filed under Boundaryless Information Flow, The Open Group, The Open Group San Francisco 2016, TOGAF, Uncategorized

Enabling the Boundaryless Organization the Goal of The Open Group Madrid Summit 2015

The Open Group, the global vendor-neutral IT consortium, is hosting its latest event in Madrid April 20 – 23 2015. The event is set to build on the success of previous events and focus on the challenge of building a Boundaryless Organization in the face of a range of new IT trends. As organizations look to take advantage of trends such as the Internet of Things and Open Platform 3.0™, the Madrid event will be an opportunity for peers to present and discuss and how the Boundaryless Organization can be achieved and what methods are best to do so.

Objectives of this year’s conference include:

  • Understanding what role Enterprise Architecture as currently practiced plays in Enterprise Transformation, especially transformations driven by merging and disruptive technologies.
  • Showing the need for Boundaryless Information Flow™, which would result in more interoperable, real-time business processes that span throughout all business ecosystems.
  • Understanding how to develop better interoperability and communication across organizational boundaries and pursue global standards for Enterprise Architecture that are highly relevant to all industries.
  • Showing how organizations can achieve their business objectives by adopting new technologies and processes as part of the Enterprise Transformation management principles – making the whole process more a matter of design than of chance.
  • Examining how the growth of “The Internet of Things” with online currencies and mobile enabled transactions has changed the face of financial services, and poses new threats and opportunities.

Key plenary and track speakers at the event include:

  • Allen Brown, President & CEO, The Open Group
  • Ron Tolido, SVP, Group CTO Office, , Global Insights and Data practice, Capgemini
  • Mariano Arnaiz, CIO, Grupo CESCE
  • Domingo Molina, Director of Information Technology and Communication Management, CNIS

Full details on the event agenda can be found here.

Registration for The Open Group Madrid is open now and available to members and non-members.  Please visit here.

Join the conversation! @theopengroup #ogMAD

1 Comment

Filed under big data, Boundaryless Information Flow™, Enterprise Architecture, Internet of Things, Interoperability, Open Platform 3.0, OTTF, Professional Development, RISK Management, Standards, Strategy, TOGAF

The Open Group San Diego Panel Explores Synergy Among Major Frameworks in Enterprise Architecture

Following is a transcript of part of the proceedings from The Open Group San Diego event in February – a panel discussion on The Synergy of Enterprise Architecture frameworks.

The following panel, which examines the synergy among the major Enterprise Architecture frameworks, consists of moderator Allen Brown, President and Chief Executive Officer, The Open Group; Iver Bank, an Enterprise Architect at Cambia Health Solutions; Dr. Beryl Bellman, Academic Director, FEAC Institute; John Zachman, Chairman and CEO of Zachman International, and originator of the Zachman Framework; and Chris Forde, General Manager, Asia and Pacific Region and Vice President, Enterprise Architecture, The Open Group.

Here are some excerpts:

By The Open GroupIver Band: As an Enterprise Architect at Cambia Health Solutions, I have been working with the ArchiMate® Language for over four years now, both working with and on it in the ArchiMate® Forum. As soon as I discovered it in late 2010, I could immediately see, as an Enterprise Architect, how it filled an important gap.

It’s very interesting to see the perspective of John Zachman. I will briefly present how the ArchiMate Language allows you to fully support enterprise architecture using The Zachman Framework. So I am going to very briefly talk about enterprise architecture with the ArchiMate Language and The Zachman Framework.

What is the ArchiMate Language? Well, it’s a language we use for building understanding across disciplines in an organization and communicating and managing change.  It’s a graphical notation with formal semantics. It’s a language.

It’s a framework that describes and relates the business, application, and technology layers of an enterprise, and it has extensions for modelling motivation, which includes business strategy, external factors affecting the organization, requirements for putting them altogether and for showing them from different stakeholder perspectives.

You can show conflicting stakeholder perspectives, and even politics. I’ve used it to model organizational politics that were preventing a project from going forward.

It has a rich set of techniques in its viewpoint mechanism for visualizing and analyzing what’s going on in your enterprise. Those viewpoints are tailored to different stakeholders.  And, of course, ArchiMate®, like TOGAF®, is an open standard managed by The Open Group.

Taste of Archimate

This is just a taste of ArchiMate for people who haven’t seen it before. This is actually excerpted from the presentation my colleague Chris McCurdy and I are doing at this conference on Guiding Agile Solution Delivery with the ArchiMate Language.

What this shows is the Business and Application Layers of ArchiMate. It shows a business process at the top. Each process is represented by a symbol. It shows a data model of business objects, then, at the next layer, in yellow.

Below that, it shows a data model actually realized by the application, the actual data that’s being processed.

Below that, it shows an application collaboration, a set of applications working together, that reads and writes that data and realizes the business data model that our business processes use.

All in all, it presents a vision of an integrated project management toolset for a particular SDLC that uses the phases that you see across the top.

We are going to dissect this model, how you would build it, and how you would develop it in an agile environment in our presentation tomorrow.

I have done some analysis of The Zachman Framework, comparing it to the ArchiMate Language. What’s really clear is that ArchiMate supports enterprise architecture with The Zachman Framework. You see a rendering of The Zachman Framework and then you see a rendering of the components of the ArchiMate Language. You see the Business Layer, the Application Layer, the Technology Layer, its ability to express information, behavior, and structure, and then the Motivation and Implementation and Migration extensions.

So how does it support it? Well, there are two key things here. The first is that ArchiMate models answer the questions that are posed by The Zachman Framework columns.

For what: for Inventory. We are basically talking about what is in the organization. There are Business and Data Objects, Products, Contracts, Value, and Meaning.

For how: for process. We can model Business Processes and Functions. We can model Flow and Triggering Relationships between them.

Where: for the Distribution of our assets. We can model Locations, we can model Devices, and we can model Networks, depending on how you define Location within a network or within a geography.

For who: We can model Responsibility, with Business Actors, Collaborations, and Roles.

When: for Timing. We have Business Events, Plateaus of System Evolution, relatively stable systems states, and we have Triggering Relationships.

Why: We have a rich Motivation extension, Stakeholders, Drivers, Assessments, Principles, Goals, Requirements, etc., and we show how those different components influence and realize each other.

Zachman perspectives

Finally, ArchiMate models express The Zachman Row Perspectives. For the contextual or boundary perspective, where Scope Lists are required, we can make catalogs of ArchiMate Concepts. ArchiMate has broad tool support, and in a repository-based tool, while ArchiMate is a graphical language, you can very easily take list of concepts, as I do regularly, and put them in catalog or metrics form. So it’s easy to come up with those Scope Lists.

Secondly, for the Conceptual area, the Business Model, we have a rich set of Business Layer Viewpoints. Like the top of the — that focus on the top of the diagram that I showed you; Business Processes, Actors, Collaborations, Interfaces, Business Services that are brought to market.

Then at the Logical Layer we have System. We have a rich set of Application Layer Viewpoints and Viewpoints that show how Applications use Infrastructure.

For Physical, we have an Infrastructure Layer, which can be used to model any type of Infrastructure: Hosting, Network, Storage, Virtualization, Distribution, and Failover. All those types of things can be modeled.

And for Configuration and Instantiation, the Application and Technology Layer Viewpoints are available, particularly more detailed ones, but are also important is the Mappings to standard design languages such as BPMN, UML and ERD. Those are straightforward for experienced modelers. We also have a white paper on using the ArchiMate language with UML. Thank you.

By The Open GroupDr. Beryl Bellman: I have been doing enterprise architecture for quite a long time, for what you call pre-enterprise architecture work, probably about 30 years, and I first met John Zachman well over 20 years ago.

In addition to being an enterprise architect I am also a University Professor at California State University, Los Angeles. My focus there is on Organizational Communications. While being a professor, I always have been involved in doing contract consulting for companies like Digital Equipment Corporation, ASK, AT&T, NCR, then Ptech.

About 15 years ago, a colleague of mine and I founded the FEAC Institute. The initial name for that was the Federal Enterprise Architecture Certification Institute, and then we changed it to Federated. It actually goes by both names.

The business driver of that was the Clinger–Cohen Bill in 1996 when it was mandated by government that all federal agencies must have an enterprise architecture.

And then around 2000, they began to enforce that regulation. My business partner at that time, Felix Rausch, and I felt that we need some certification in how to go about doing and meeting those requirements, both for the federal agencies and the Department of Defense. And so that’s when we created the FEAC Institute.

Beginning of FEAC

In our first course, we had the Executive Office of the President, US Department of Fed, which I believe was the first Department of the Federal Government that was hit by OMB which held up their budget for not having an enterprise architecture on file. So they were pretty desperate, and that began the first of the beginning of the FEAC.

Since that time, a lot of people have come in from the commercial world and from international areas. And the idea of FEAC was that you start off with learning how to do enterprise architecture. In a lot of programs, including TOGAF, you sort of have to already know a little bit about enterprise architecture, the hermeneutical circle. You have to know what it is to know.

In FEAC we had a position that you want to provide training and educating in how to do enterprise architecture that will get you from a beginning state to be able to take full responsibility for work doing enterprise architecture in a matter of three months. It’s associated with the California State University System, and you can get, if you so desire, 12 graduate academic units in Engineering Management that can be applied toward a degree or you can get continuing education units.

So that’s how we began that. Then, a couple of years ago, my business partner decided he wanted to retire, and fortunately there was this guy named John Zachman, who will never retire. He’s a lot younger than all of us in this room, right? So he purchased the FEAC Institute.

I still maintain a relationship with it as Academic Director, in which primarily my responsibilities are as a liaison to the universities. My colleague, Cort Coghill, is sort of the Academic Coordinator of the FEAC Institute.

FEAC is an organization that also incorporates a lot of the training and education programs of Zachman International, which includes managing the FEAC TOGAF courses, as well as the Zachman certified courses, which we will tell you more about.

‘m just a little bit surprised by this idea, the panel, the way we are constructed here, because I didn’t have a presentation. I’m doing it off the top, as you can see. I was told we are supposed to have a panel discussion about the synergies of enterprise architecture. So I prepared in my mind the synergies between the different enterprise architectures that are out there.

For that, I just wanted to make a strong point. I wanted to talk about synergy like a bifurcation between on the one hand, “TOGAF and Zachman” as being standing on one side, whereas the statement has been made earlier this morning and throughout the meeting is “TOGAF and.”

Likewise, we have Zachman, and it’s not “Zachman or, but it’s ‘Zachman and.” Zachman provides that ontology, as John talks about it in his periodic table of basic elements of primitives through which we can constitute any enterprise architecture. To attempt to build an architecture out of composites and then venting composites and just modeling  you’re just getting a snapshot in time and you’re really not having an enterprise architecture that is able to adapt and change. You might be able to have a picture of it, but that’s all you really have.

That’s the power of The Zachman Framework. Hopefully, most of you will attend our demonstration this afternoon and a workshop where we are actually going to have people work with building primitives and looking at the relationship of primitives, the composites with a case study.

Getting lost

On the other side of that, Schekkerman wrote something about the forest of architectural frameworks and getting lost in that. There are a lot of enterprise architectural frameworks out there.

I’m not counting TOGAF, because TOGAF has its own architectural content metamodel, with its own artifacts, but those does not require one to use the artifacts in the architectural content metamodel. They suggest that you can use DoDAF. You can use MODAF. You can use commercial ones like NCR’s GITP. You can use any one.

Those are basically the competing models. Some of them are commercial-based, where organizations have their own proprietary stamps and the names of the artifacts, and the wrong names for it, and others want to give it its own take.

I’m more familiar nowadays with the governmental sectors. For example, FEAF, Federal Enterprise Architecture Framework Version 2. Are you familiar with that? Just go on the Internet, type in FEAF v2. Since Scott Bernard has been the head, he is the Chief Architect for the US Government at the OMB, he has developed a model of enterprise architecture, what he calls the Architecture Cube Model, which is an iteration off of John’s, but he is pursuing a cube form rather than a triangle form.

Also, for him the FEAF-II, as enterprise architecture, fits into his FEAF-II, because at the top level he has the strategic plans of an organization.

It goes down to different layers, but then, at one point, it drops off and becomes not only a solution, but it gets into the manufacturing of the solution. He has these whole series of artifacts that pertain to these different layers, but at the lower levels, you have a computer wiring closet diagram model, which is a little bit more detailed than what we would consider to be at a level of enterprise architecture.

Then you have the MODAF, the DoDAF, and all of these other ones, where a lot of those compete with each other more on the basis of political choices.

With the MODAF, the British obviously don’t want to use DoDAF, they have their own, but they are very similar to each other. One view, the acquisition view, differs from the project view, but they do the same things. You can define them in terms of each other.

Then there is the Canadian, NAF, and all that, and they are very similar. Now, we’re trying to develop the unified MODAF, DoDAF, and NAF architecture, UPDM, which is still in its planning stages. So we are moving toward a more integrated system.

BrownAllen Brown: Let’s move on to some of the questions that folks are interested in. Moving away from what the frameworks are, there is a question here. How does enterprise architecture take advantage of the impact of new emerging technologies like social, mobile, analytics, cloud, and so on?

Bidirectional change

John A Zachman: The change can take place in the enterprise either from the top, where we change the context of the enterprise, or from the bottom, where we change the technologies.

So technology is expressed in the context of the enterprise, what I would call Rule 4, and that’s the physical domain. And it’s the same way in any other — the building architecture, the airplane architecture, or anything. You can implement the logic, the as-designed logic, in different technologies.

Whatever the technology is, I made an observation that you want to engineer for flexibility. You separate the independent variables. So you separate the logic at Rule 3 from the physics of Rule 4, and then you can change Rule 4 without changing Rule 3. Basically that’s the idea, so you can accommodate whatever the emerging technologies are.

Bellman: I would just continue with that. I agree with John. Thinking about the synergy between the different architectures, basically every enterprise architecture contains, or should contain, considerations of those primitives. Then, it’s a matter of which a customer wants, which a customer feels comfortable with? Basically as long as you have those primitives defined, then you essentially can use any architecture. That constitute the synergy between the architectures.

Band: I agree with what’s been said. It’s also true that I think that one of the jobs of an enterprise architect is to establish a view of the organization that can be used to promote understanding and communicate and manage change. With cloud-based systems, they are generally based on metadata, and the major platforms, like Salesforce.com as an example. They publish their data models and their APIs.

So I think that there’s going to be a new generation of systems that provide a continuously synchronized, real-time view of what’s going on in the enterprise. So the architectural model will model this in the future, where things need to go, and they will do analyses, but we will be using cloud, big data, and even sensor technologies to understand the state of the enterprise.

Bellman: In the DoDaF 2.0, when that initially came out, I think it was six years ago or so, they have services architecture, a services view, and a systems view. And one of the points they make within the context, not as a footnote, is that they expect the systems view to sort of disappear and there will be a cloud view that will take its place. So I think you are right on that.

Chris Forde: The way I interpreted the question was, how does EA or architecture approach the things help you manage disruptive things? And if you accept the idea that enterprise architecture actually is a management discipline, it’s going to help you ask the right questions to understand what you are dealing with, where it should be positioned, what the risks and value proposition is around those particular things, whether that’s the Internet of Things, cloud computing, or all of these types of activities.

So going back to the core of what Terry’s presentation was about is a decision making framework with informed questions to help you understand what you should be doing to either mitigate the risk, take advantage of the innovation, and deploy the particular thing in a way that’s useful to your business. That’s the way I read the question.

Impact of sensors

Band: Just to reinforce what Chris says, as an enterprise architect in healthcare, one of the things that I am looking at very closely is the evaluation of the impact of health sensor technology. Gartner Group says that by 2020, the average lifespan in a developed country will be increased by six months due to mobile health monitoring.

And so there are vast changes in the whole healthcare delivery system, of which my company is at the center as a major healthcare payer and investor in all sorts of healthcare companies. I use enterprise architecture techniques to begin to understand the impact of that and show the opportunities to our health insurance business.

Brown: If you think about social and mobile and you look at the entire enterprise architecture, now you are starting to expand that beyond the limits of the organization, aren’t you? You’re starting to look at, not just the organization and the ecosystem, your business partners, but you are also looking at the impact of bringing mobile devices into the organization, of managers doing things on their own with cloud that wasn’t part of the architecture. You have got the relationship with consumers out there that are using social and mobile. How do you capture all of that in enterprise architecture?

Forde: Allen, if I had the answer to that question I would form my own business and I would go sell it.

Back in the day, when I was working in large organizations, we were talking about the extended enterprise, that kind of ecosystem view of things. And at that time the issue was more problematic. We knew we were in an extended ecosystem, but we didn’t really have the technologies that effectively supported it.

The types of technologies that are available today, the ones that The Open Group has white papers about — cloud computing, the Internet of Things, this sort of stuff — architectures can help you classify those things. And the technologies that are being deployed can help you track them, and they can help you track them not as documents of the instance, but of the thing in real time that is talking to you about what its state is, and what its future state will be, and then you have to manage that information in vast quantities.

So an architecture can help you within your enterprise understand those things and it can help you connect to other enterprises or other information sources to allow you to make sense of all those things. But again, it’s a question of scoping, filtering, making sense, and abstracting — that key phrase that John pointed out earlier, of abstracting this stuff up to a level that is comprehensible and not overwhelming.

Brown: So Iver, at Cambia Health, you must have this kind of problem now, mustn’t you?

Provide value

Band: That’s exactly what I am doing. I am figuring out what will be the impact of certain technologies and how our businesses can use them to differentiate and provide value.

In fact, I was just on a call this morning with JeffSTAT, because the whole ecosystem is changing, and we know that healthcare is really changing. The current model is not financially sustainable, and there is also tremendous amount of waste in our healthcare system today. The executives of our company say that about a third of the $2.7 trillion and rising spent on healthcare in the US doesn’t do anyone any good.

There’s a tremendous amount of IT investment in that, and that requires architecture to tie it altogether. It has to do with all the things ranging from the logic with which we edit claims, to the follow-up we provide people with particularly dangerous and consequently expensive diseases. So there is just a tremendous amount going through an enterprise architecture. It’s necessary to have a coherent narrative of what the organization needs to do.

Bellman: One thing we all need to keep in mind is even more dynamic than that, if you believe even a little bit of Kurzweil’s possibilities is that — are people familiar with Ray Kurzweil’s ‘The Singularity Is Near’ — 2037 will be around the singularly between computers and human beings.

So I think that the wrap where he argues that the amount of change is not linear but exponential, and so in a sense you will never catch up, but you need an architecture to manage that.

By The Open GroupZachman: The way we deal with complexity is through classification. I suggest that there is more than one way to classify things. One is one-dimensional classification, taxonomy, or hierarchy, in effect, decompositions, one-dimensional classification, and that’s really helpful for manufacturing. From an engineering standpoint of a two-dimensional classification, where we have classified things so that they are normalized, one effect in one place.

Then if you have the problems identified, you can postulate several technology changes or several changes and simulate the various implications of it.

The whole reason why I do architecture has to do with change. You deal with extreme complexity and then you have to accommodate extreme change. There is no other way to deal with it. Humanity, for thousands of years, has not been able to figure out a better way to deal with complexity and change other than architecture.

Forde: Maybe we shouldn’t apply architecture to some things.

For example, maybe the technologies or the opportunity is so new, we need to have the decision-making framework that says, you know what, let’s not try and figure out all this, just to self-control their stuff in advance, okay? Let’s let it run and see what happens, and then when it’s at the appropriate point for architecture, let’s apply it, this is a more organic view of the way nature and life works than the enterprise view of it.

So what I am saying is that architecture is not irrelevant in that context. It’s actually there is a part of the decision-making framework to not architect something at this point in time because it’s inappropriate to do so.

Funding and budgeting

Band: Yeah, I agree that wholeheartedly. If it can’t be health solutions, we are a completely agile shop. All the technology development is on the same sprint cycle, and we have three-week sprints, but we also have certain things that are still annual and wonderful like funding and budgeting.

We live in a tension. People say, well, what are you going to do, what budget do you need, but at the same time, I haven’t figured everything out. So I am constantly living in that gap of what do I need to meet a certain milestone to get my project funded, and what do I need to do to go forward? Obviously, in a fully agile organization, all those things would be fluid. But then there’s financial reporting, and we would also have to be fluid too. So there are barriers to that.

For instance, the Scaled Agile Framework, which I think is a fascinating thing, has a very clear place for enterprise architecture. As Chris said, you don’t want to do too much of it in advance.  I am constantly getting the gap between how can I visualize what’s going to happen a year out and how can I give the development teams what they need for the sprint. So I am always living in that paradox.

Bellman: The Gartner Group, not too long ago, came up with the concept of emerging enterprise architecture and what we are dealing with. Enterprises don’t exist like buildings. A building is an object, but an enterprise is a group of human beings communicating with one another.

As a very famous organizational psychologist Karl Weick once pointed out, “The effective organization is garrulous, clumsy, superstitious, hypocritical, mostrous, octopoid, wandering, and grouchy.” Why? Because an organization is continually adapting, continually changing, and continually adapting to the changing business and technological landscape.

To expect anything other than that is not having a realistic view of the enterprise. It is emerging and it is a continually emerging phenomena. So in a sense, having an architecture concept I would not contest, but architecting is always worthwhile. It’s like it’s an organic phenomena, and that in order to deal with that what we can also understand and have an architecture for organic phenomena that change and rapidly adapt.

Brown: Chris, where you were going follows the lines of what great companies do, right?

There is a great book published about 30 years ago called ‘In Search of Excellence.’ If you haven’t read it, I suggest that people do. Written by Peters and Waterman, and Tom Peters has tried for ever since to try and recreate something with that magic, but one of the lessons learned was what great companies do, is something that goes simultaneous loose-tight properties. So you let somethings be very tightly controlled, and other things as are suggesting, let them flourish and see where they go before I actually box them in. So that’s a good thought.

So what do we think, as a panel, about evolving TOGAF to become an engineering methodology as well as a manufacturing methodology?

Zachman: I really think it’s a good idea.

Brown: Chris, do you have any thoughts on that?

Interesting proposal

Forde: I think it’s an interesting proposal and I think we need to look at it fairly seriously. The Open Group approach to things is, don’t lock people into a specific way of thinking, but we also advocate disciplined approach to doing things. So I would susspect that we are going to be exploring John’s proposal pretty seriously.

Brown: You mentioned in your talk that decision-making process is a precondition, the decision-making process to govern IT investments, and the question that comes in is how about other types of investments including facilities, inventory and acquisitions?

By The Open GroupForde: The wording of the presentation was very specific. Most organizations have a process or decision-making framework on an annual basis or quarterly whatever the cycles are for allocation of funding to do X, Y or Z. So the implication wasn’t that IT was the only space that it would be applied.

However, the question is how effective is that decision-making framework? In many organizations, or in a lot of organizations, the IT function is essentially an enterprise-wide activity that’s supporting the financial activities, the plant activities, these sorts of things. So you have the P&Ls from those things flowing in some way into the funding that comes to the IT organization.

The question is, when there are multiple complexities in an organization, multiple departments with independent P&Ls, they are funding IT activities in a way that may not be optimized, may or may not be optimized. For the architects, in my view, one of the avenues for success is in inserting yourself into that planning cycle and influencing,  because normally the architecture team does not have direct control over the spend, but influencing how that spend goes.

Over time gradually improving the enterprise’s ability to optimize and make effective the funding it applies for IT to support the rest of the business.

Zachman: Yeah, I was just wondering, you’ve got to make observation.

Band: I agree, I think that the battle to control shadow IT has been permanently lost. We are in a technology obsessed society. Every department wants to control some technology and even develop it to their needs. There are some controls that you do have, and we do have some, but we have core health insurance businesses that are nearly a 100 years old.

Cambia is constantly investing and acquiring new companies that are transforming healthcare. Cambia has over a 100 million customers all across the country even though our original business was a set of regional health plans.

Build relationships

You can’t possibly rationalize all of everything I want you to pay for on that thing. It is incumbent upon the architects, especially the senior ones, to build relationships with the people in these organizations and make sure everything is synergetic.

Many years ago, there was a senior architect. I asked him what he did, and he said, “Well, I’m just the glue. I go to a lot of meetings.” There are deliverables and deadlines too, but there is a part of consistently building the relationships and noticing things, so that when there is time to make a decision or someone needs something, it gets done right.

Zachman: I was in London when Bank of America got bought by NationsBank, and it was touted as the biggest banking merger in the history of the banking industry.

Actually it wasn’t a merger, it was an acquisition NationsBank acquired Bank of America and then changed the name to Bank of America. There was a London paper that was  observing that the headline you always see is, “The biggest merger in the history of the industry.” The headline you never see is, “This merger didn’t work.”

The cost of integrating the two enterprises exceeded the value of the acquisition. Therefore, we’re going to have to break this thing up in pieces and sell off the pieces as surreptitiously as possible, so nobody will notice that we buried any accounting notes someplace or other. You never see that article. You’ll only see the one about the biggest merger.

If I was the CEO and my strategy was to grow by acquisition, I would get really interested in enterprise architecture. Because you have to be able to anticipate the integration of the cost, if you want to merge two enterprises. In fact, you’re changing the scope of the enterprise. I have talked a little bit about the role on models, but you are changing the scope. As soon as you change a scope, you’re now going to be faced with an integration issue.

Therefore you have to make a choice, scrap and rework. There is no way, after the fact, to integrate parts that don’t fit together. So you’re gong to be faced a decision whether you want to scrap and rework or not. I would get really interested in enterprise architecture, because that’s what you really want to know before you make the expenditure. You acquire and obviously you’ve already blown out all the money. So now you’ve got a problem.

Once again, if I was the CEO and I want to grow by acquisition or merger acquisition, I would get really interested in enterprise architecture.

Cultural issues

Beryl Bellman: One of the big problems we are addressing here is also the cultural and political problems of organizations or enterprises. You could have the best design type of system, and if people and politics don’t agree, there are going to be these kind of conflicts.

I was involved in my favorite projects at consulting. I was involved in consulting with NCR, who was dealing with Hyundai and Samsung and trying to get them together at a conjoint project. They kept fighting with each other in terms of knowledge management, technology transfer, and knowledge transfer. My role of it was to do an architecture of that whole process.

It was called RIAC Research Institute in Computer Technology. On one side of the table, you had Hyundai and Samsung. On the other side of the table, you had NCR. They were throwing PowerPoint slides back and forth at each other. I brought up that the software we used at that time was METIS, and METIS modeled all the processes, everything that was involved.

Samsung said you just hit it with a 2×4. I used to be demonstrating it, rather than tossing out slides, here are the relationships, and be able to show that it really works. To me that was a real demonstration that I can even overcome some of the politics and cultural differences within enterprises.

Brown: I want to give one more question. I think this is more of a concern that we have raised in some people’s minds today, which is, we are talking about all these different frameworks and ontologies, and so there is a first question.

The second one is probably the key one that we are looking at, but it asks what does each of the frameworks lack, what are the key elements that are missing, because that leads on to the second question that says, isn’t needing to understand old enterprise architecture frameworks is not a complex exercise for a practitioner?

Band: My job is not about understanding frameworks. I have been doing enterprises solution architecture in HP at a standard and diversified financial services company and now at health insurance and health solutions company out for quite a while, and it’s really about communicating and understanding in a way that’s useful to your stakeholders.

The frameworks about creating shared understanding of what we have and where are we going to go, and the frameworks are just a set of tools that you have in your toolbox that most people don’t understand.

So the idea is not to understand everything but to get a set of tools, just like a mechanic would, that you carry around that you use all the time. For instance, there are certain types of ArchiMate views that I use when I am in a group. I will draw an ArchiMate business process view with application service use of the same. What are the business processes you need to be and what are the exposed application behaviors that they need to consume?

I had that discussion with people on the business who are in IT, and we drove those diagrams. That’s a useful tool, it works for me, it works for the people around me, it works in my culture, but there is no understanding over frameworks unless that’s your field of study. They are all missing the exact thing you need for a particular interaction, but most likely there is something in there that you can base the next critical interaction on.

Six questions

Zachman: I spent most of my life thinking about my frameworks. There are six questions you have to answer to have a complete description of whatever it is, what I will describe, what, how, where, who, and why. So that’s complete.

The philosophers have established six transformations interestingly enough, the transfer of idea into an instantiation, so that’s a complete set, and I did not invent either one of these, so the six interrogatives. They have the six stages of transformation and that framework has to, by definition, accommodate any factor that’s relevant to the existence of the object of the enterprise.  Therefore any fact has to be classifiable in that structure.

My framework is complete in that regard. For many years, I would have been reluctant to make a categorical statement, but we exercised this, and there is no anomaly. I can’t find an anomaly. Therefore I have a high level of confidence that you can classify any fact in that context.

There is one periodic table. There are n different compound manufacturing processes. You can manufacture anything out of the periodic table. That metaphor is really helpful. There’s one enterprise architecture framework ontology. I happened to stumble across, by accident, the ontology for classifying all of the facts relevant to an enterprise.

I wish I could tell you that I was so smart and understood all of these things at the beginning, but I knew nothing about this, I just happened to stumble across it. The framework fell on my desk one day and I saw the pattern. All I did was I put enterprise names on the same pattern for descriptive representation of anything. You’ve heard me tell quite a bit of the story this afternoon. In terms of completeness I think my framework is complete. I can find no anomalies and you can classify anything relative to that framework.

And I agree with Iver, that there are n different tools you might want to use. You don’t have to know everything about every framework. One thing is, whatever the tool is that you need to deal with and out of the context of the periodic table metaphor, the ontological construct of The Zachman Framework, you can accommodate whatever artifacts the tool creates.

You don’t have to analyze every tool, whatever tool is necessary, if you want to do with business architecture, you can create whatever the business architecture manifestation is. If you want to know what DoDAF is, you can create the DoDAF artifacts. You can create any composite, and you can create any compound from the periodic table. It’s the same idea.

I wouldn’t spend my life trying to understand all these frameworks. You have to operate the enterprise, you have to manage the enterprise and whatever the tool is, it’s required to do whatever it is that you need to do and there is something good about everything and nothing necessarily does everything.

So use the tool that’s appropriate and then you can create whatever the composite constructs are required by that tool out of the primitive components of the framework. I wouldn’t try to understand all the frameworks.

What’s missing

Forde: On a daily basis there is a line of people at these conferences coming to tell me what’s missing from TOGAF. Recently we conducted a survey through the Association of Enterprise Architects about what people needed to see. Basically the stuff came back pretty much, please give us more guidance that’s specific to my situation, a recipe for how to solve world hunger, or something like that. We are not in the role of providing that level of prescriptive detail.

The value side of the equation is the flexibility of the framework to a certain degree to allow many different industries and many different practitioners drive value for their business out of using that particular tool.

So some people will find value in the content metamodel in the TOGAF Framework and the other components of it, but if you are not happy with that, if it doesn’t meet your need, flip over to The Zachman Framework or vice versa.

John made it very clear earlier that the value in the framework that he has built throughout his career and has been used repeatedly around the world is its rigor, it’s comprehensiveness, but he made very clear, it’s not a method. There is nothing in there to tell you how to go do it.

So you could criticize The Zachman Framework for a lack of method or you could spend your time talking about the value of it as a very useful tool to get X, Y, and Z done.

From a practitioner’s standpoint, what one practitioner does is interesting in a value, but if you have a practice between 200 and 400 architects, you don’t want everybody running around like a loose cannon doing it their way, in my opinion. As a practice manager or leader you need something that makes those resources very, very effective. And when you are in a practice of that size, you probably have a handful of people trying to figure out how the frameworks come together, but most of the practitioners are tasked with taking what the organization says is their best practice and executing on it.

We are looking at improving the level of guidance provided by the TOGAF material, the standard and guidance about how to do specific scenarios.

For example, how to jumpstart an architecture practice, how to build a secure architecture, how to do business architecture well? Those are the kinds of things that we have had feedback on and we are working on around that particular specification.

Brown: So if you are employed by the US Department of Defense you would be required to use DoDAF, if you are an enterprise architect, because of the views it provides. But people like Terri Blevins that did work in the DoD many years, used TOGAF to populate DoDAF. It’s a method, and the method is the great strength.

If you want to have more information on that, there are a number of white papers on our website about using TOGAF with DoDAF, TOGAF with COBIT, TOGAF with Zachman, TOGAF with everything else.

Forde: TOGAF with frameworks, TOGAF with buy in, the thing to look at is the ecosystem of information around these frameworks is where the value proposition really is. If you are trying to bootstrap your standards practice inside, the framework is of interest, but applied use, driving to the value proposition for your business function is the critical area to focus on.

The panel, which examined the synergy among the major EA frameworks, consists of moderator Allen Brown, President and Chief Executive Officer, The Open Group; Iver Bank, an Enterprise Architect, Cambia Health Solutions; Dr. Beryl Bellman, Academic Director, FEAC Institute; John Zachman, Chairman and CEO of Zachman International, and originator of the Zachman Framework; and Chris Forde, General Manager, Asia and Pacific Region and Vice President, Enterprise Architecture, The Open Group.

Transcript available here.

Join the conversation @theopengroup #ogchat

You may also be interested in:

 

2 Comments

Filed under ArchiMate®, big data, Business Architecture, Cloud, Data management, Enterprise Architecture, Enterprise Transformation, Standards, TOGAF®, Uncategorized