Cloud –hype or a lesson to learn about ongoing technology change

A while back the model was there was a market for just 10 mainframes worldwide, or so the quote goes.  The in order for a corporation to join the big boys, you needed your own.  Decades later I’ve the equivalent of a S/360 processing power in my pocket.  If one follows the technology generations: On-Prem. Mainframe; Department Minis; Timeshare; PCs; Client-Server; then Internet, Now Cloud. There is always a new technology on the horizon (e.g., quantum computing) that will solve the worlds problems and put the kids to bed on time or so the marketing hype goes.

I’m neither a fan-boy or luddite when it comes to new technology.  I believe I’m a pragmatist.  I’ve a set of simple rules when it comes to acquisition and holding onto technology:

• Explore and examine, but do not commit till conditions point to such
• When exploring the technology, examine both the technological aspects:
  • does it add new capabilities
  • Is it stable (mature enough, reliable enough, has enough market share to continue a reasonable lifespan)
• and business application:
  • does that new capability add something to my business
    • Reach to customers or markets
    • Improve customer relationships
    • Allow me to do something new for customer or improve my operations
  • or reduce costs and risks

Which brings me to the latest R&D I’ve been conducting over the past few decades that fits into my larger research project of creating a CAD/CAM system for Enterprise Design, Construction, Operations, and  Remodeling.   That latest research has been all about the overlap between business and technology strategy.  This is something my mentor John Zachman had started decades ago.  By now I can imagine several people’s eyes rolling. “Zachman Framework!, that so yesterday…”  However, those that have seen the decades of methodology hype go by know that the Ontology expressed in the Framework still is relevant.  Its just not the “silver bullet” everyone wants.  It takes some work to understand that the views defined in the Framework are there for a reason: To understand the various aspects of an abstract entity, Enterprise, to be manifested.

Given the hype and technology priesthoods that have developed around various methodologies: TOGAF, DODAF, SAFe, BPMN, etc.. I will not enter into the fray, other than to say these all have some aspect of utility and all address some dimensions in the Zachman Framework. 

Back to Cloud and business/technology strategy:  As of late business models or various levels of business models (Campbell’s Operation Model Canvas**) are become more mature from decades ago and starting to reach across to technology or rather technology has been identified as an enabler to business strategy.  With that as an underpinning to this post.  I post the real question around Cloud and Cloud Hype:

The real issue is how or should you take advantage of such. If you’re just switching technology to “modernize” that’s fine.  If the cost of maintenance or business continuity risk due to end of life is a significant threat changing technologies is a simple model (i.e., you’re replacing you car because you can’t get anything more out of your Model T).  That does suggest however, it will be running business as usual.

That, in my opinion, is short sighted as few businesses are in an environment that enables that.  Today business as unusual is the norm.  There is so much volatility and change going on in the space we call enterprise that operating a business is now more an effort of managing complexity and change than executing a simple production line was twenty or thirty years ago.  As such prior to committing to such a change it behooves Executives to ask the questions beyond the easy just replace On-Premise with On-Cloud for a supposed cost saving, how will I exploit the technology to improve my business besides just keep it operating another day?  As well as ask what are the trade-offs I make with such choices:

• Dependencies/Risks on a service provider
  • Will they be around tomorrow
  • Will the service change
  • Besides Security and Data Ownership, can I extract such to a new provider should I decide to
• Will/Can I integrate a broad spectrum of services together (primary vendor and others) with moderate or less effort, or is it really a closed system
• How long will it take to covert?  Will the conversion take more time than the technology is likely to be in place

The thing I tell my clients continually, there is no free lunch, there are always trader-offs.  Some immediately, Some during an event, and Some eventually (i.e., in the future).  It is up to your executive team, not the technology providers or operators within the company, to understand these implications and impacts.  -And if your team does not have the confidence in making these decisions get a Business – Technology Strategy Consulting firm to assist.  This is not a technology strategy consulting firm (i.e., how to install, configure, and operate), but one that focuses on how-to use the technology for business as well as what are its implications to the business.

**full disclosure I’m working with Andrew Campbell on a tool suite to evaluate Operating Models similar to the evaluation tool suite I built for the Business Model Canvas community

Structure in Threes: Revised Preface and start of Part One/Chapter One – An Architect’s View of Organizations

PREFACE

It has been close to thirty years since John Zachman coined the term Enterprise Architecture and introduced business to the Zachman Framework. Over the years, the metaphor has been used and abused, technical religions have grown around methodologies and still the term Enterprise Architecture is derisive.

• Is it an activity that produces a plan for building various systems?
• Is it the actual plan for an Enterprise?
• Is it a methodology to produce standard compliant designs?
• Is it a collection of diagrams that represent different types of information about the information systems used in an enterprise (the Zachman Framework Aka Ontology)
• Or maybe a specific set of standard components organized in a specific structured way

When I started the initial concept for this book years ago, I had considered creating a text that would provide methods for designing an enterprise; this being the goal of Enterprise Architecture or at least my belief is the goal. However, over the years’ experience has taught me five things:

1. Nothing is simple when explaining yourself; a lesson taught to me by John Zachman
2. Words have different meanings depending upon the context and experience of others; a lesson taught by Michael Kutcher, John Sowa, Gil Laware, and Frank Kowalkowski
3. The difference between a methodologist and a terrorist is that you can negotiate with the terrorist; a lesson taught by IBM CIM Architecture Department and TC184/SC4 & SC5 working groups
4. Thinking in the abstract and in multiple dimensions while technically possible by most, is often avoided in most enterprises in the name of speed and comprehension; a lesson taught by most managers and mid-level executives I’ve had to deal with
5. Nothing is foolproof as fools are so dam cleaver and Nature always sides with the hidden flaw; Murphy you were an optimist

Those insights came to light over the years of associating and working with those I consider giants and mentors in the field. Included in this book are vignettes of how those insights were developed; if for no other reasons than to pay tribute to my mentors and colleagues and to establish part of the context for the content in the book.

That being the bedrock I started building this work upon, I realized I needed to answer several questions first before I introduced my approach to Enterprise Architecture. The book itself is meant to be a practical guide on “practicing” Enterprise Architecture, a theoretical text explaining my perspective on what Architecture or more specifically Enterprise Architecture is, and how these fundamentals are expressed in practice.

Why Structure in Threes

Structure in Threes praxis guide toward the design of enterprise based upon a fusion of several concepts:

• A classic work from Henry Mintzberg, Structure in Fives, on strategy
• My original research and training in dwelling architecture from works by Vitruvius, Soleri, and Christopher Alexander
• Studies in Systems Theory from works from von Bertalanffy, Checkland, Forrester, Meadows, and Weinberg
• Studies and learnings from John Zachman

The title is meant both to honor Mintzberg’s leap of using a spatial reference to describe an abstract subject as well Zachman’s ontology that defines a multi-dimensional problem space that is enterprise.

About this book

This book is both a stand-alone work as well as a companion text for an educational curriculum taught by the author. The sole purpose of both book and curriculum is to raise the knowledge and skill level of practicing architects and associated stakeholders. While it will reference a methodology for demonstration it should not be construed as THE sole approach towards developing a praxis.

Simply put I am not intending to form yet another priesthood in the field. There are many paths to this destination and fulfilling the goal of designing an effective enterprise.

Part One – Theory and Methodology

 

An Architect’s View of Organizations – creating a coordinate system for an abstract space

In 1997 I had published an article “What is Architecture” to lay out the context for the full problem space I believe enterprise architecture should cover. In this article, I recounted an earlier discussion with several IT provider executives that I worked with. Primarily the dispute was around the representations of architecture, but quickly moved past representations to what architecture is.

My opponent in this discussion strongly advocated documenting a set of components in a hierarchy. “Here the architecture is these six devices connected together by this specific network type. That’s the architecture” He’d laid out a hierarchy of computing systems that looked much like an organizational hierarchy; One master mainframe at the top with a descending hierarchy of smaller and smaller mainframes, and eventually workstations or personal computers.

I had asked what was the rationale behind using a hierarchy and the selection of each component type at each level. The response was a blank stare. It was though I was speaking Martian to him. Then suddenly a rather heated response back. “O.k. tell me YOUR definition of architecture”.

Without trying to escalate what had become a heated situation I fell back to my original training. “There is a difference between architecture and design. Many people use the term architecture when they really mean a design….an architecture are the rules for the selection and usage of components and/or elements to achieve a stated functional objective. These can be structural and non-structural such as light & shadow, space, stone, glass and wood. This how these components are selected, used to fulfill an objective is the architecture. The actual instance of using these are the design.”

Defining the problem-solution space

From that discussion and the Zachman Framework I came to the conclusion that to effectively design and construct an enterprise one really needed to visualize this conceptual entity, Enterprise” in an abstract multi-dimensional space. A similar concept to how architects use the dimensional metaphor to define dwellings. What is missing in those dwelling visualizations (designs) are the rules that were used to create those designs. That is the architecture that was developed inside the head of the architect during his/her education and practice.

However, in discussion of those components, elements, and rules has not been a topic of discussion in most Enterprise Architecture narratives or methodologies. Instead what has been taught and discussed has been documentation/representation practices. This is equivalent to teaching drafting standards. And when rules are discussed it typically has been around sizing of components, not selection and use. Occasionally one gets into discussions around implementations: Mainframe vs Network, Network vs Cloud, etc. These are typically religious wars from vendors attempting to justify why their products are better or inclusion in the latest technology theme.

Hoping to avoid such conflicts, the first part of this text is aimed at providing the theoretical foundations for the reader to move past such religious wars by establishing the coordinate space for discussions on why and in what context to select and use.

Strategy, Resource, and Structure – the three dimensions of Organizations

Keeping with the theme of threes I believe that Strategy, Resource, and Structure are the primary dimensions of this abstract space where enterprise can be defined. This may seem to go counter to the Zachman ontology, however, if one looks at the ontology in an architecture context, the various dimensions are actually views of an enterprise. Thus, each box in the framework is a projection of one or more of these primary dimensions.

Class Structures in Dimensions

One other aspect of these primary dimensions is that each is actually a family of instances based upon the context in which these are used. A simple example, there are corporate organizational structures, software structures, business structures, etc. Each describes the arrangement and relationship between components. These will be discussed further in each dimension section to follow.

[Preview/Outline] Constraints in Design – Money Changes Everything

1. Money is both resource and measurement system for the game
2. Perishable Resource -Time the one resource that can’t be stored for later use
3. People – the multiplier resource

KPIs – Key Performance Inhibitors and a method to transform theses back to Indicators

This month I am dividing my time between several initiatives at work:

• Technology development activities
• Process adoption
• Metrics definition
• Skills transfer

A rather interesting and eclectic combination of activities. But as I started to ponder these I started to reflect on the metrics definition activities of past and the relationship to other initiatives on my list. My goal is to create a suite of KPIs for my group that is useful in advancing our success. With that premise several things come to mind.

• KPIs or metrics that truly indicate how the organization is progressing to its goals; rather than those fool us into believing we’re doing well when we’re not
• KPUs that the organization believes in; that is, we have control in positively effecting these and can relate to achievement of our goals
• KPIs that are diagnostic; they provide insights to help us determine what we can do better

This is a tall order considering people often are suspicious of how measurements are used. Especially if such has been used in the past not as guidance but justification for other agendas. This typically results in KPIs that are meaningless but always show green, even in the face of disaster. Such have a witnessed before within sales organizations that measured success by size of backlog rather than quality of backlog or customer satisfaction. This eventually became a game of musical chairs with the unlucky sales rep. at the end of the cycle taking the hit for a bad backlog he had nothing to do with.

Based upon such experience, my belief is that KPIs need to be a serious discussion and negotiation between all levels within the organization. Staff must believe that these measurements are able to be influenced by their actions; Management must believe these measurements indicate status of the journey to goal achievement.

These seem simple enough, except that the altitude that each party operates at is different. If you’re a Senior Executive you’re often looking at corporate performance: profit/loss, customer satisfaction, market share, etc. If you’re a programmer in IT you’re focus is on cost and time of delivering an application, response time of system, uptime, etc. This difference in metrics can and often does create misalignment between management and staff.

The results of which is often KPIs become Key Performance Inhibitors as staff become disillusioned with measurements as they can’t relate their measurements with goals management focuses on rather than how their measures relate to business measurements.

This conundrum can be address with a method called Hoshin Planning. Hoshin Planning is nothing more than a cascading set of matrices of goals, strategies, and measurements that relate one altitude of measurements to another. While the technique works well, it does require additional effort between management and staff to be explicit about the goals, tactics and measurements as well as reasonable in setting measures and targets that assignees believe are achievable. This however, is not a simple twenty-minute exercise and like all planning requires constraint revision in the light of new information (i.e., planning forecasts are not accounting transactions).

Is Enterprise Architecture Completely Broken?

IASA Question Is Enterprise Architecture Completely Broken?

EA –that is credited to John Zachman– originally was “A framework for information systems architecture” a tool for MIS (aka IT) to “design” the components needed to support business objectives.  This was an evolution from a former methodology “BSP”  Business System Planning –also from IBM– which provide information to MIS directors and Business Executives to plan budgets/investments.  Later this budget prioritization was advanced by Parker-Benson in BEAM (refer to Information Economics).  EA roles became split into two camps:  Budgeting and Design.  The problems arise in that both roles forgot that the architecture role was that of facilitator rather than decision-maker and the primary stakeholders don’t have dialogs with these role holders typically.  This leaves rise to EAs creating visions and actions to create local optimizations.

Of course it is not too often that EAs are placed in a position that has the exposure and influence necessary to fulfill the role’s perceived charter.  Thus often EAs are glamorized programmers or software engineers granted the title after years of hard work in their domain by HR.  This gives them the title but not the scope or enterprise orientation.

More impactful to that position of influence; what CEO, COO or other CxO would grant that power to a non-executive.  While HR has toyed with titles such as CTO and CIO, the role of Chief Architect for enterprise has yet to be established in any meaningful way and has challengers to that title.  Books like “CFO, Architect of the business” are popular fair in the book trade.   And why would a COB/CEO/COO create such a role if they feel their role should be that, even if they don’t have the necessary architecture skills -after all they climbed to the top and are thus “entitled” to wear that crown.   However, it then gets back to a view of what an architect does/is.  Two schools or architecture: Architect as Decision-Maker, Architect as Facilitator/Advisor of Stakeholder’s Vision.

If one looks at chief design roles in other disciplines which have had more time to mature you’ll discover that such roles take years to develop an understanding beyond the mechanics of the discipline and how it fits in context beyond just building something.  This the senior role-holder must have a broader background than just Agile Development, DFD modeling, etc. and needs to step out into understanding the enterprise as a living organism. My recommendation is to study the Cybernetic Hierarchy in General Systems Theory to get beyond “Frameworks” and “Clockworks” through Adaptive/Dynamic Systems to Transcendental Systems.  These later types of systems capture more than frameworks do.  However with increases of information, increased thinking time is required to understand such data; something executives are in short supply of these days.

IT Planning and Agile

Some of the new organizations I’m dealing with are going crazy with “Agile”.  The Hype Cycle  is in full force.  Soon Agile with be advertised to put the kids to bed on time, solve world peace, and feed the world.  The problem I see is not with Agile its with its close cousin “Addle” which is often what I see organizations implementing (I.e., the worst of each methodology glued together).   I will point out that I am neither a zealot for Waterfall or Agile; its a tool and like other power tools –notice the woodworking reference– it should be used carefully.  Too often I’ve seen Agile be used for an excuse for poor or no planning and/or poor development practices.

If one reads the original materials, nowhere does it say don’t plan.  Actually it indicates you need plans, just not at the level of precision and scope previously and wrongly drummed into people’s heads.  Agile suggests or recommends planning in short enough horizons such that the problem doesn’t change before you finishes planning (accuracy) and to a granularity (precision) that is enough to get the job done.  Another way to look at it:

If my problem was to cross the river and you spent five years planning to build a bridge, by the time you actually built the bridge I may have cross the river with a boat and now I’m faced with climbing a mountain (problem has changed).  If I want something to sit on I may want a chair, but it may not need to be designed and constructed to 1 millionth of an inch tolerance –which would cost a significant amount.  I could probably get by with 1/32 of an inch, produced at lower cost but yielding the same level of performance I desire.  So in the end Agile is a balancing act that I believe still requires planning; just different types of planning and a whole lot of thinking.

 

Structure in Threes: Budgeting and Planning -observations and muses

The beatings will continue until moral improves, or so goes the typical planning cycle each year.  Although being an observer of the process in many enterprises for 30 years and a unwilling participant at times, I would classify these activities as anything but planning.  These are more like the High School Senior Prom with all the politics and drama leading up to the final ceremonies.  Management spends hours of their as well as staff time building a case to justify their groups existence rather than actually looking at how and what to contribute to the enterprise’s bottom like.  Then having to “re-plan”  funding / headcount don’t match political expectations.

It doesn’t have to be this war dance each year.  Developing a real enterprise portfolio management system could remedy this, however, methodology zealots (aka methodologist, of which I’m sad to say I associate myself with) often get caught up in the minutia rather than the goes.  A joke I’m fond of telling during presentations when asked about strict adherence to any methodology might clue you into my worries about methodologies that too often become dogma:  What’s the difference between a terrorist and a methodologist? Answer: You can negotiate with a terrorist.

Much of the research and design work I’ve done over the years is now starting to converge:  Process Modeling (IDEF0 & BPMN),  Simulation and Analysis of systems (System Dynamics and Viable Systems Models), Digital Nervous System (AD), IT Economics ( ISIS, Information Economic/BEAM, REJ, and VRF) and now integrating financial Portfolio Management Concepts with VA/VE and Systems Engineering Concepts with the focus on designing enterprises like one would design any other product or service.  As I near competition of my basic research for Modern IT Portfolio Management I look forward to thinking about how to deploy and enable adoption.  Now that the basics of a digital nervous system are in place, its time to create the “brain of the firm “which I see is a portfolio management system connected to the DNS driven by people making fact based decisions.

The one caveat to using this approach is taking it too far, enterprises are composed of people as are markets.  And people are emotional, thus making decisions that address attempts at gratification for those emotions.  Thus Portfolio management needs to be applied with flexibility to not only accommodate this phenomena but exploit it in the positive sense.  Then perhaps budgeting and planning will be more of a constructive than destructive activity, creating intrapreuers in the company.

Structure in Threes: Building vs Planning

One of the problems systemic to the design and planning world is the often famous quote:  “Its done its just a small matter or implementation or programming or etc.”  All too often I’ve seen designers or planner consider the job done once the design is finished.  However, there is often a lot of work to get it accomplished; even it there are not changes to the design.  This got me thinking about the terminology used in regard to projects.  To me implementation take is a larger concept than just deployment which seems to be the typical thoughts around projects, especially in IT.  “The application has been installed we’re done”.  True implementation carries with it both deployment and adoption, anything less is just dumping.

The proposed remedy to this is to have adoption KPIs included in project metrics, not just development cost and schedule.  This would foster a greater concern that what is built is actually used.

Structure in Threes: IT Business Models

Early

Yesterday on the way back from client’s site I started pondering the intersection of Service Quality, Brand Value, and Business Models with regard to Information Technology.  Traditionally, IT functions had been focused around a product development model with operations being dragged in tow as a little more than after market support.  The only difference was that IT had a captive market or so the unconscious bias appears to be within these organizations.  As the IT industry has aged, other goal expectations were placed upon these organizations.  These ranged from being the gatekeeper to precious information, the controller for allocating technology & resources, and the integrating force between other parts of the organization. Whether it is possible for one function to successfully execute on all three missions is a topic for another post.

These expectations struck a nerve with me as I was reading Step Guide for Building a Great Company .  I have been researching business strategy, models and processes for most of my career.  As I read through the first few pages I wondered if IT Functions were not using the wrong business model.  In the past decade many IT functions are desperately trying to change their culture to a service oriented business.  Initiatives such as ITIL, COBIT, and SOA seek to inject a service mindset.  I think the objective is a laudable.  Having experienced a slightly less than customer / service oriented environment decades ago (a story for another time over a beer).

However, the typical service model that is put in place is one for a stabilized or mature business.  A business that has a standardized set of services that are being optimized, not a service that is constantly evolving which has been the nature of the IT function over the past several decades: Mainframes, PC/Workstations, Network, Internet, and now Cloud and BYOD.  This would not be considered a stable and mature industry as the technology keeps changing.  The  consider as the technology keeps changing new services are being either asked for or developed constantly.

With that fact I wonder if the business model IT functions should use is that of a Startup or possibly a bifurcated model that has service groups start out in incubators and move into optimization models as the service matures.  This is very similar to the extension’s I developed for another employer with regard to managing business portfolios.  I had based much of the initial work on The Alchemy of Growth: Practical Insights for Building the Enduring Enterprise adding another horizon and much more recently figuring out how to tie each horizon portfolio together using Real Options and Cluster Analysis.

In this recent expansion new services in ideation are considered a new business opportunity or new technology opportunity.  This determines if they are a Horizon 3 or Horizon 4 portfolio member.  As the internal market/business develops or the technology becomes understandable and stable enough to pilot these opportunities move onto the next portfolio where different operating rules and metrics are applied to manage these.

The result of using such a model makes the IT Function vertically integrated business incubator going from Founder & Angel Investor, to Startup & Venture Capitalist, to an stabilized operating line of business.   Which leads to yet another simulation model to build for my clients and possible discussion at next April’s Engineering Conference.

Structure in Threes IT Lifecycle Management: EOL

Spent a few minutes during breakfast pondering some of the issues around IT Lifecycle Management.  Specifically the term End of Life (EOL).  IT community is still a little behind other engineering disciplines in its understanding and application of this concept.  Take S/W for instance.  There EOL typically means either no more support for the product or that the product has been withdrawn from the market.  That is on the vendor’s side of the equation.  On the customer side EOL has other implications.  Does the application still operate and provide utility?  If so EOL is really a transition from vendor support to self-service;  think out of warranty for your car.  A third level of consequence are the customers of IT, the Line of Business that use the service based upon the application.  Does EOL of the application mean EOL for the service or does it mean a mad scramble to replace the utility by some other means.

 

This brings me back to the nuances I am exploring in Portfolio Management.  Currently one of the failings of IT Portfolio Management has been the lack of linkage between service utility and application serviceability in managing a portfolio.  Too often have a seen that second and third order consequences were not considered during portfolio decisions.  Y2K issues a decade ago are just one ripple effect of short term decision making.  The hierarchical model of portfolio I’ve been prototyping and testing appears to address this issue.  I’ve started to look at applying via usage strategies of Active Directory which was what I had considered when we came up with the conceptual design.  Only a decade or so behind schedule.  However, Cloud technologies may make implementations easier and harder now.  IT Financial Management approaches are on an upswing again so the timing might be right

Insights: Meetings

Occasionally I have the luxury of sitting back and watching project meetings as an FYI attendee rather than a active participant.  During a recent meeting that was to set context for a direction change and gain buy-in from stakeholders I watched as the two meeting leads followed a careful script crafted the previous day gradually spun off track.  These were two seasoned professionals with more than a few years experience.  People I highly respect. So what happened?

Like so many other group meetings, both the pre-meeting developing the script for the buy-in meeting and the buy-in meeting,  understanding the roles at the table and there agendas was not prime on the mines of the participants.  Often in meetings I find we –and I’ll include myself in this pattern– are more interested in our own specific agenda than achievement of the overall goal of the team or scoring points in intellectual arguments on detail procedures rather than outcomes.  While the pre-meeting had established its goal of gaining buy-in from the stakeholders the approach to gaining such was less thought out.  The team spent time creating a logical agenda to present what and why we were going to do differently.  This was done optimistically or blindly in the believed if the logic was correct we’d get buy-in.  While we got some agreement, the buy-in meeting slowly drifted away as stakeholders 1) raised issues that were not covered in the presentation but were of importance to them and 2) had a different understanding of terms, concepts, methods and how these are combined for results.  Even the outcomes expected generated controversy.  The goals of each stakeholders were different than the goals of the project or rather achievement of these stakeholder goals were not necessarily supportive of the overall goal of the project.  That is not to say these goals were counter to achievement of the project, but these needed to be aligned in context of the overall project.

Which brings me back to the corrective action we should have taken during the pre-meeting.  Years ago I brought to the attention of my management an article in Sloan Management Review : A Framework for Managing IT-Enabled Change,  Summer 1993 July 15, 1993 Robert I. Benjamin and Eliot Levinson.   I was promptly told to bury the article, we don’t do that here in this company.  Such effort would be seen as manipulation rather than good leadership practices.

In that article they had an approach towards visually planning gaining stakeholder buy-in which would have served us well.  However, while some progress in language regarding gaining stakeholder buy-in has improved in the IT profession, considered focus and concern in that direction are still merely a follow the numbers activity.  Would the meeting have been different, more productive, and gained agreement -no commitment- faster had we used this approach.  I don’t know for sure.  I expect it would as it had worked for me very well at other companies, but I would have like to have seen it tried.

The other insight gained from the meeting was really a reminder that terms and concepts are not always understood by everyone in the same manner  These are influenced by the context and role people play within a particular situation. This is especially true in the business process domain which is very abstract and often leans itself to multiple interpretations to terms, many times drifting off as a new label to old ways of doing business rather than the new approach it was suppose to be.