Wednesday, April 23, 2014

The Zachman Framework - The Perfect Tool for Operating Model Management



I have written previously on this blog about leveraging Enterprise Architecture as a methodology for the Operating Model creation and management. In this blog post I will briefly outline mechanism and benefits of using industry leading Zachman Framework as a specific tool for Operating Model creation and management. 

The Zachman Framework, initially named as A Framework for Information Systems Architecture, by John Zachman was published in an 1987 article in the IBM Systems journal. Since then it has been revised and enhanced by John Zachman a few times and the current version 3.0 is now owned and managed by the Zachman International.  The current version 3.0 shown below is available on its website. 

ZF3.0sm
Zachman Framework for Enterprise Architecture
All copyrights with Zachman International


On this blog I have covered various aspects of Zachman Framework and thinking behind it from John in a number of posts. His thoughts on using the framework to address complexity and changethe framework being ontology - a classification for Enterprise Assets and components are well documented in my previous posts and hence I won't repeat in this post. I will try and briefly cover how the latest version can be used to address the Operating Model creation and management challenges.

Zachman is a two dimensional schema; the first dimension "the Abstractions" offers a way to classify the Organisational Operating Model from six unique aspects;
  1. What -  the Inventory Models within the Organisation e.g. List of Products
  2. How - the Process Models within the Organisation e.g. Product Selling Process, Product Definition Process, Pricing Process etc. 
  3. Where - the Distribution Models within the Organisation e.g. the Locations where Product is designed, sold, supported etc.
  4. Who - the Roles & Responsibility Models within the Organisation e.g. who plays what role in Product Sell Process, who is responsible for Servicing
  5. When - the Timing Models or Cyclical Models of the Organisation e.g. Peak / Off-Peak season of Product demand, When to release a new product
  6. Why - the Motivation Models or Business Objectives which drive the Organisation e.g. "Be the leader in xyz Product Market", "Exit a Segment"
The second dimension of the Zachman Framework "the Perspectives" presents a classification system to record different view points depending on your roles. The framework offers six unique perspectives;

  1. The Executive Perspective - Typically board members and executive leadership perspective which defines the business context along with scope and boundaries of the Enterprise (or a large transformation or a division depending on what problem is Operating Model addressing)
  2. The Business Management Perspective - Typically business unit director's, P&L owner's, Product manager's perspective which defines business concepts , definitions, high level requirements for the Enterprise (or a product or a service or a division, depends on what problem you are solving)
  3. The Architect Perspective - No this is not about IT yet...this is the perspective of the business logic designer, logical modeler who represents the Business Management Perspectives in logical constructs or structures such as Models, Design Logic etc. 
  4. The Engineer Perspective - This perspective covers technology models, physical models, specifications. Something which bring logical models close to physical reality
  5. The Technician Perspective - This perspective is all about implementation, tools configuration, applying tools and converting physical models into reality
  6. The Enterprise Perspective - This is the End User Perspective and covers the actual implementation. e.g. single product management system deployed in 12 different physical markets across different divisions. 

I am probably running out of time and space to explain all the interactions across these two dimensions in a single blog post (I will probably add a few posts on this later)...but just to cover a few specific points about Operating Model creation or management...

  • Operating Model is created through a series of transformations....from first perspective, the Executive Vision, Scope, Context through to Definitions, Logical Models, Physical Models, Configuration / Build and Implementation. 
  • The 6x6 Matrix of Perspectives and Abstractions contain only "primitives" - single entity only at a time and does not contain complex structure "composites". 
  • This enables effective reuse of Enterprise Elements and isolating problems on one variable at a time. The idea is two (or more) primitives then can have interactions to create composites. e.g. Inventory is Processed across Locations by Roles at a specific Time to achieve a Goal.
  • John compares this Primitive Vs Composites to Engineering Vs Manufacturing. Operating Model creation is an Enterprise Engineering Task not Manufacturing Task. 
  • And by the way the classification system ensure that you are engaging right stakeholders and asking right questions along as you progress. 
  • You can create all sorts of interaction matrices as it suits your business problem. E.g. if you are solving the "Cost Reduction" problem a matrix of Data Entities, Locations, Roles Vs Process will easily surface the most redundant Roles, Locations, Processes by following above steps. 
I will just break a major myth and then stop this post...YOU DO NOT HAVE TO BOIL THE OCEAN TO DO ENTERPRISE ARCHITECTURE. You can choose the single, most important business problem and model that using this framework. It may be a specific product launch or a redesign of a geography or a business unit, similar concepts work. I rather prefer doing this in small chunks in a meaningful way to deliver business goals than do modelling for the sake of it for months. 

And before you ask, Zachman is a Framework. A Framework is a Structure. TOGAF is a Methodology. Methodology is a Process. A Structure defines something, a Process transforms something. It's not either or both have their own purpose depending on what you are trying to achieve. 

So in summary if you are defining operating model for an entire enterprise or single division, use primitive elementary modelling using this 6x6 matrix and arrive at an Operating Model in iterative way. I will probably share some more example matrices in future posts. 


On a personal note....
Amit with John in a recent Zachman Workshop

John is still the driving force behind it and I have been privileged to understand this framework or this classification system from him a number of times in recent past. John's passion for thinking of Enterprise Architecture as the enterprise business classification system needs to be understood, communicated and developed further by Enterprise Architecture community. I still hear a few architects or even a few senior architecture managers associating Enterprise Architecture only with technology. Please don't sell Enterprise Architecture short, don't undermine the capabilities and possibilities offered by this tool / method / framework. Applying it to resolve most complex organisation enterprise problems such as Operating Model is the perfect application scenario.

Monday, January 27, 2014

Transformation Business Model in Minutes?

For the past few months I have been busy helping Retail, Financial Services and Public Sector on their Digital, Multi-Channel and E-Commerce Transformation programs. Very early on in such transformation challenge, defining the business case for change often proves a challenge. You know that organisation, often successful in what they do currently, need to change. Not just from IT perspective but such change is often required from business and operating model perspective, services, product and offering perspective. But the challenge often is to articulate, qualify and quantify in terms of real tangible and sometime intangible business benefits. 

At the moment I am working with Argos the leading high-street retailer in the UK which is going through such a transformation where it is evolving fast into a digital retailing leader. For a fast paced retailer another challenge is, how do we get this business case / model finalised quickly, in an agile way and how do we get stakeholder buy-in quickly. While working with an Agile project team I came across a good tool "Lean Canvas". It seems to be building on the ideas from business model generation. I am still exploring the tool but thought it looks promising. Below is an illustrative model built using the tool.

Google Business Model

Source - https://twitter.com/pjthyssen/status/427689964944773120/photo/1

Friday, July 12, 2013

Business Architecture & Enterprise Architecture – Match Made in Heaven

I recently spoke at the European BPM and EA Conference in London on this topic. This blog post is a summary version of my session.

Often Business Process Management and associated discipline such as Business Architecture is seen or managed in isolation of the overarching Enterprise Architecture construct. However the Business Architecture and Enterprise Architecture complement each other well to get the best value from each other. I think that the Business Architecture is one of the key enablers of the Enterprise Architecture and makes it real. While the Enterprise Architecture offers much needed context for the Business Architecture.

It might be useful to briefly review the definitions of both Business Architecture and Enterprise Architecture before understanding issues in their relationship. 

As I have been writing on this blog, Enterprise Architecture should not be limited to the IT or Technology concerns of an organisation. Rather it should be focused on addressing much broader scope covering the business, functional, operational, financial and people aspects of the enterprise. 

There are a number of Enterprise Architecture definitions out there. A couple of my favorite ones are as follows:

Enterprise Architecture provides a strategic planning framework that relates and aligns information technology with the business functions that it supports.

Or

Practice of enterprise architecture involves developing a framework to describe a series of "current", "intermediate" and "target" reference architectures and applying them to align change within the enterprise. Another set of terms for these are "as-is", "to-be" and the "migration plan".


The Business Architecture Special Interest Group of Object Management Group (OMG) defines Business Architecture as follows:

“A Blueprint of the Enterprise That Provides A Common Understanding Of The Organization And Is Used To Align Strategic Objectives And Tactical Demands.”


“Business Architecture describes the product and/or service strategy, and the organizational, functional, process, information, and geographic aspects of the business environment”

I think that though the practice of both Business Architecture and Enterprise Architecture has matured over the past few years, there certainly are some issues when it comes to these two working well together. I have summarised them in four broad arguments;

  1. Business Architecture not done at all. Enterprise Architecture teams only perform Enterprise Technical Architecture only.
  2. Business Architecture done in isolation of Enterprise Technical Architecture and then (if lucky) artificially superimposed
  3. Business Architecture and Business Context Confusion: confusion between why, what and how
  4. Technology focused governance: only conversations about technical standards, business governance disconnected from IT investment and decisions leading to critical gaps
I have tried to capture this pictorially below:

BA & EA in Isolation

This issue is getting wider acknowledgment given its strategic importance. I particularly like Randy Heffner’s work in this space. He states in one of his blogs;

“Simply positioning business architecture as a layer on top of existing EA domains is a mistake. Traditionally many organisations have pursued EA as Enterprise Technical Architecture (ETA). ETA is technology-centred.  Business architecture is business-centred. Simply layering it on top of ETA will result in tech-centred silo implementation.”


As Business Architecture Special Interest Group of Object Management Group (OMG) states, the Business Architecture defines the structure of the enterprise in terms of its governance structure, business processes, and business information. In defining the structure of the enterprise, business architecture considers customers, finances, and the market to align strategic goals and objectives with decisions regarding products and services; partners and suppliers; organization; capabilities; and key initiatives. Business Architecture primarily should focus on the business motivations, business operations and business analysis frameworks and related networks that link these aspects of the enterprise together and it should be seamlessly integrated with Enterprise Architecture efforts within the organisation. 

In my experience to tackle above listed issues, following measures can be taken by the Architecture team;

  1. Business Architecture as part of Enterprise Architecture
  2. Business Architecture drives Enterprise Architecture domains
  3. Business Architecture and Business Context clarified and integrate
  4. Business aligned Technology governance


My pictorial representation from earlier changes as below now:


BA & EA in Collaboration


Modern Enterprise Architecture teams and Enterprise Architects can not longer afford to ignore the implications of Business Architecture. Likewise, modern business architects can no longer afford to work in isolation of organisation’s enterprise architecture. 

In conclusion of this article I would like to summarize my thoughts as follows:

  1. Enterprise Architecture in isolation of Business Architecture is simply Enterprise Technical Architecture
  2. Business Architecture should guide the development of Enterprise Architecture domains
  3. Business Architecture combined with Enterprise Architecture is a powerful tool for business-IT alignment
  4. Strategic Frameworks and Models help in achieving this alignment

And as Chris Potts would argue, the Chief Executive of an Organisation should be ultimately accountable for ensuring the two come together as we would expect him or her to be the Chief Enterprise Architect of the Enterprise!

For related articles:


Thursday, June 20, 2013

Building Blocks of Your Enterprise Mobile Strategy

Given my current focus on Multi-Channel architecture & technology programs for Retail and Logistics customer in UK&I, I am often on a look out for new ideas, trends and business case studies. This interest took me to the IBM Enterprise Mobile Summit earlier this week in London Southbank. It was a compact but impressive gathering of Mobile industry experts, suppliers and consumers. It did help me crystallize my thoughts around Enterprise Mobile Strategy which I am trying to summarize in this blog post.   

When an Enterprise (commercial organisation) makes an investment decision to develop a Mobile Strategy (e.g. Mobile Applications or Apps) and related products or services, it should do so based on strategic enterprise intent (or in certain instances tactical response). This investment should take into account a number of stakeholder perspectives such as Functional, Development, Delivery, Operations, End-User Consumer and the Market.

IBM MobileFirst
The Strategic Intent and drivers behind Enterprise Mobile Investment – 
Before committing funds on Mobile strategy a valid question to ask is, what is your Enterprise attempting to achieve by mobile investment? For instance do you see mobile evolving as one of your primary channel to market? Are you attempting to gather insights from mobile data which may provide new opportunities for product and services expansion? 

Or are you simply trying to increase your business transactions though Mobile media. In some instances it may be seen as a media for extending the brand experience for more personal shopping or browsing experience.

The Enterprise Functional Perspective – If the purpose of Mobile strategy is to address internal organisation efficiency then the functional objectives need to focus on employee and organisation productivity enhancement. For instance how can a Mobile App transform, optimise internal work flow and may be also enhance the customer interactions. KPIs here could be reduction of complexity, reduction in wastage, improving quality, faster time to market etc. As I observed in IBM session, some of IBM customers are using the Mobile strategy to extend Enterprise business network in new ways. For instance an Italian organisation leveraged Mobile Apps to find promotions in their network and connected people to these promotions. Michael Gilfix of IBM in this session also cited IBM’s own example of how Mobile strategy is driving next level of productivity by acknowledging its global workforce segmentation.

The Development Lifecycle Perspective – During the session both Michael Gilfix of IBM and Jessica Figueras, a Mobile Industry Analyst highlighted a point that there is a difference between creating conventional Apps and Mobile Apps. Mobile development and developers need to understand the Mobile App consumption patterns, workflows and user interaction in different ways. IBM briefly shared their Mobile Development Lifecycle process which comprises of iterative phases such as; Design & Develop, Instrument, Integrate, Test, Scale & Certify, Deploy, Manage, Obtain Insight and back to Design & Develop. Jessica made a good point that Mobile Apps are becoming more and more complex and they need Enterprise Architecture underpinning them to be successful.

The IT Delivery and Operations Perspective – The above point about Enterprise Architecture requirements extends into the Operational and Delivery aspects of IT too. Challenge of Fragmentation is particularly important; how best to serve different fragmented devices to serve multi-channel experience which is a different challenge that Web Apps where one size often fits all consumers. Michael was also keen to point our Security and Access control aspects such as Loss of control over distribution, impact of BYOD, Control of data and access as code often would run in environment outside of Enterprise control. From the customer satisfaction perspective, the end-user of Mobile Apps will look out for and increasingly expect consistent multi-channel experience. e.g. Airline - phone, kiosk, in-flight, travel experience.

The consumer perspective: Creating compelling mobile user experience – Ali Al-Shakarchi, the UX Architect and Strategist from IBM had some very interesting themes on this perspective which can be argued as the most important factor to make Mobile strategy successful. He highlighted the fact that, user expectations are high and user tolerance is low when it comes to Apps as the competition is fierce, an alternative App is a tap away. Some of the tips which Ali shared were; Stay Relevant, Keep it simple, Build richer experience, Think innovation, Optimise for mobile, Create end to end experience, Be more social and evolve on an ongoing basis in a smart way.

Some of the demos / case studies during the session further underlined some of above points. The Barclays Pingit case study and how it is driving the C2C is a prime example of how Apps can bring success and create new Operating Models for large Enterprises. While the Tealeaf demo effectively showcased the power of analytics behind smart Mobile strategy. 


One of the key takeaway for me was, "Why limit Mobile conversations to IT? Focus must be on exploring business opportunities & enhancing business capabilities". I would like to congratulate IBM for putting together a smart, effective and useful summit. I certainly hope to apply some of the above lessons learnt for my customers in Retail and Logistics in near future. 

For more on IBM Mobilefirst read here

Monday, June 17, 2013

BPM & EA Conference London, 2013 - My Learning Experience

Last week I attended the Enterprise Architecture and BPM conference in London, probably first of its kind of joint conference organised by folks at IRM UK. I have been attending IRM European Enterprise Architecture Conference since 2005 and have witnessed it grow and mature over past 7 or 8 years. I would like to think of IRM Europe EA Conference as the "Open Source"version compared to other EA conferences which appear more "Proprietary" in their subject matter and presentation. IRM conference seems to be a more open and welcoming of a range of diverse views and opinions which are dominating current and future EA scene. 

Amit with John Zachman @ IRM UK Conference
So what did I learn in this year's conference? By now "the traditional" John Zachman's session on day one was as always one of the highlights of the event for me. John was his self; passionate and energetic for the cause of Enterprise Architecture. His session demonstrated Enterprise Architecture progressiveness of thinking, purpose, flexibility and sheer focus on the business relevance of Enterprise Architecture. This year John's session was around the new Zachman Framework (version 3) and emphasizing the framework as Ontology and not as a process or method. Zachman is not a methodology, it is a scheme for classification of Enterprise aspects or components. In his own words, "Zachman framework schema technically is an Ontology, a theory of the existence of a structured set of essential components of an object for which explicit expression is necessary for design, operating and changing the object (object being an Enterprise or department or value chain, solution, project, building etc)". 

John was very clear to point out that a framework does not do anything on its own, it is a simple classification of an object. One needs to have set of methodologies to create the Ontology or classification per a schema, in this instance Zachman. I think he also very succinctly pointed out differences between Zachman and TOGAF, underlining importance of a methodology and process offered by TOGAF to enable the classification of Enterprise components.  By the way, just to clarify we are not discussing Enterprise Architecture limited to IT only, we are discussing it in the broader sense of wider business and organisation. If it was not clear already, John very clearly stated at the start of the session that Enterprise Architecture is not just about IT. We discussed where and who is best placed to undertake such as exercise? According to John, an executive in charge of managing change within the Enterprise should be the sponsor of Enterprise Architecture efforts. 

On this point, following session by Chris Potts was so interesting. Chris picked up the discussions promptly where John had left it, probably not by design. Chris very early on set the stall and clarified that the ultimate sponsor of Enterprise Architecture should be the Chief Executive, as his books make it clear, Chief Executive of an Organisation is the ultimate Enterprise Architect of that Enterprise. Chris then went onto cover some of the influencing tactics of EA. He discussed the example of Burberry as a successful Enterprise the role its chief designer Chris Bailey has played in it. He liked the role of this designer to Enterprise Architect. We talked about the consistency of the brand for Burberry, right from its website, to its promotions, to its shops and how value proposition of Enterprise Architecture must have made the difference for that business. 

We then discussed the Enterprise Investment as the End-to-End process and how Enterprise Architects should be differentiating between different stakeholder perspectives; e.g. Investor perspective and expectations vs. that of Program Manager perspective and expectations.  To me this was one of the key takeaways; how best can Enterprise Architect be relevant to Enterprise objectives and various perspectives to offer best possible value proposition. As a juggler of many conflicting priorities, "play or pass" discussion was also very important. If you are an Enterprise Architect, you are playing a rare role and there are not many resources like you in the Enterprise. How best can you deploy this resource to maximize your effectiveness and influence? Chris proposed four criteria to measure the influence and effectiveness: does EA contribution lead to substantial innovation? Does this boost the overall Enterprise performance? Does it help the Investor perspective? And where can EA be having maximum influence as a result of playing the "game". The dashboard to summarize this I thought was very useful. 

There were a number of interesting case studies which I thought demonstrated new EA practices and new EA thinking. I particularly liked the Bath and North East Somerset Council, JPMorgan, Credit Suisse and EDF cases as they discussed real problems which we as EA face and how they overcame them. This year was unique in the sense that, IRM had combined the EAC and BPM conference and to me this was almost a bonus as under the same roof, I not only could listen to EA experts and practitioners but also listen to BPM experts such as Paul Harmon and Roger Burlton. Paul's session on "State of BPM" and Roger's session on "Business Capabilities" was particularly outstanding while I thought case studies from Mars, BA on BPM were excellent too. I will try to summarize above mentioned session in future posts as I think they do deserve a separate analysis dedicated for topics which they presented and discussed. 

Despite of me being an Enterprise Architecture practitioner for the past ten years, listening to fellow EA practitioners is like a learning experience for me. Their problems, their approaches, their pragmatism hopefully helps me negotiate that next tricky curve. As someone said during the conference, the field of Enterprise Architecture is still so young compared other established science or arts disciplines. There is lot to learn for all of us and learning experiences such as these indeed help.

All and all certainly a conference well worth attending and my personal congratulations to IRM UK, Conference Chair Chris Potts, Conference Panel Team for putting together one of the most relevant and modern  and open EA conference. And my personal thanks to number of speakers and practitioners who shared their knowledge, experiences and views over 3 or 4 days. I will certainly recommend readers of this blog to enroll for next conference! 

Blog Archive