Inside Architecture

Notes on Enterprise Architecture, Business Alignment, Interesting Trends, and anything else that interests me this week...

September, 2010

Posts
  • Inside Architecture

    Linthicum’s Challenge: Where does SOA stop and EA start?

    • 0 Comments

    Tom Graves, David Linthicum, and I recently got into an interesting discussion on Twitter as the result of a, EBiz blog post by David, where he makes the statement that Good SOA is the same as Good EA.  (See 'Do SOA and enterprise architecture now mean the same thing?' Yes, they do’).  Both Tom and I maintain that SOA is a good practice for an EA to endorse, but that it does not equate to good EA.  In this post, I’ll answer the question “why?”

    I’ll include the last few tweets for context.  Tom started the thread by noting that he disagreed with David’s premise. I joined in.

    Nick Malik

     nickmalik

    thx @tetradian for pointing out @DavidLinthicum - SOA *is* good IT arch but EA is far more than IT arch, so SOA != EA.


    Tom noted
    Tom Graves

     tetradian

    @DavidLinthicum SOA is a (useful) *style* of architecture, not architecture itself - EA must include what happens when the power goes down


    David replied, quoting my tweet and responding (emphasis added):
    DavidLinthicum

     DavidLinthicum

    RT @nickmalik & @tetradian SOA *is* good IT arch but EA is far more than IT arch, so SOA != EA.<-Love to hear where SOA stops and EA starts.


    So this post is about answering David’s question: where does SOA stop and EA start?

    Let’s start with the mission of Enterprise Architecture.  In a prior post, I discussed the mission, vision, and business capabilities of Enterprise Architecture.  To quote from that prior post:

    Enterprise Architecture exists to do two things:

    1. to Envision an organization that includes the strategic and operational changes that leaders require and demand, and
    2. to Guide changes to the structure of the organization, and the actions of the business units themselves, so that the vision becomes reality.

    Look carefully.  Do you see anything about SOA in that mission… or even information technology? 

    Enterprise Architecture envisions an organization in its entirety (structures, responsibilities, roles, processes, systems, information, and technologies).  We don’t get to choose to ignore some parts of the puzzle and focus on other parts.  When you solve a problem, you have to consider all of the factors that will come into play.  Enterprise Architecture is accountable for guiding changes to organizations where those changes are necessary to solve a problem. 

    What problems are we solving?  Usually, we focus on problems created when an organization is not ready… ready to respond to a new business strategy, ready to respond to a competitive threat, ready to respond to a market opportunity, ready to respond to change.  There are many ways to focus on the problems of the business.  Below are a few that fall within the scope of Enterprise Architecture:

    1. To make sure that the business has decision making mechanisms in place that create trust, apportion accountabilities, measure and report on results, and encourage accountability. 
    2. To make sure that the organization’s abilities (and flaws) are well understood and documented, so that when a change is proposed, valid and useful information is available to the business to make decisions, approach trade-offs, and focus resources on the specific issues that could prevent the business from making that change. 
    3. To make sure that the business frames their strategies and goals in a manner that is aligned with their intent, are prioritized to minimize internal conflicts, and clarifies the specific, measurable, actionable, realistic, and time-bound (SMART) tactics that must be implemented in order to make them come to pass.
    4. To insure that potential innovations in the marketplace, environment, and competitive space have a fair and reasonable mechanism for being considered.  This has the effect of creating the “funnel of ideas” that the IT group can use to feed in potential technical innovations.  The same funnel, BTW, is used to feed in information about competitive threats, new business opportunities, product innovations, etc.
    5. To insure that appropriate models of information are created and to guide the development of information management practices that help to reduce the complexity and difficulty of managing the consistency, accuracy, reliability, timeliness, and security of the information assets of the business.
    6. To insure that the processes used by the business to perform core or supporting business functions are well understood, and that the appropriate attention is paid to making process improvements when the business strategy demands it.
    7. To guide the development of business services that allow for the simple composition of business processes in such a way that the information can flow readily to the appropriate people, that the customer is delighted with the result, and that the stated business goals of the business can be met in a timely and agile manner.
    8. To guide the development of technology services that allow for the simple composition of business systems in such a way that the systems are reliable, available, and appropriately manageable, so that the business is not constrained in their ability to create the necessary compositions implied in the prior step.

    Depending on how you define SOA, Service Oriented Architecture is either item 7 (business services) and 8 (information services), or just item 8 (information services), in the list above.  Occasionally, SOA is used to describe a mechanism that can support item 5 (information quality mgmt), but recognize that SOA, at its finest, is not sufficient to actually accomplish that item.  It is useful, and very valuable, but not sufficient. 

    So, David, the answer to your question… what does EA do that rises above and beyond SOA?  The answer is listed in items 1, 2, 3, 4, 5, 6, and depending on your definition of SOA, 7 above. 

    Other than that, SOA is really great.

  • Inside Architecture

    A roadmap to BPM democratization

    • 6 Comments

    A few days ago, I blogged about a talk provided by Phil Gilbert at the BPM2010 conference.  In that talk, Phil made a compelling case that the smart people who are working on BPM systems and solutions are WORKING ON THE WRONG THINGS.  It was a clarion call to action.  Phil had to leave the conference and head back to IBM headquarters, but I’ve been able to stay and listen to the results.  While I agree with what Phil said, I have not heard any discussions along the lines of “what should we be adding to BPM software in order to address the things that Phil discussed?” 

    No one is taking the next step to discuss what changes need to be made, to existing software, in order to meet the challenge that Phil described.  I’d like to take him up on his challenge and describe a way to create an entire BPM stack that would be useful.   First, a summary of the problem.

    Phil’s challenge

    Phil had been asked to talk about “the future of BPM.”  As a former executive of Lombardi software, which was recently acquired by IBM, he has some credibility on the topic.  His presentation was very well put together.  I summarized his slides to a single image (my apologies to Phil… but this is a blog after all).

    image

    If you look at the numbers of people who work in a typical business, you will see that IT folks are a tiny fraction of the total number.  The above diagram tries to illustrate an (arbitrary) eight-to-one ratio.  This is a good thing.  The work of software developers is well leveraged.  For a small number of software developers, their work can benefit a large number of business people.  (Note: for the sake of this conversation, we are assuming that process modelers actually work for the IT department.  The following logic holds true if they do not work for IT, so please bear with me). 

    This is nice and good, but…

    The BPM tools on the market today provide solutions to business people, but are not designed for business people to actually use to solve their problems.  A business person has to charter some kind of project, and get one of those rare IT people to come sit with them to model their process and build a custom solution.  In other words, IT uses BPM tools.  The future of BPM lies in the world where the business uses BPM tools.  Why?  Because the vast majority of the business value of a BPM solution, according to Phil, comes from the cumulative value of automating a large number of small workflow processes.  Phil called them “Excel and e-mail” workflows. 

    And now, here comes the challenge:

    Until we work to bring about BPM democratization, we are doing the wrong things.  If we spend considerable time working on the semantics of an OR gate, but we fail to address this concept, we are limiting the reach, and therefore the ability, of BPM to succeed.  Challenge: bring about this change.

    My observations

    I asked a few folks about Phil’s challenge.  In fact, I asked folks every chance I got.  I find the idea fascinating, but I don’t believe we are all that close to it.  Here is what I noticed:

    First problem… the sales model

    Most BPM tool vendors have a sales model that goes like this:

    1. convince company that they need a BPM tool
    2. sell them licenses and consulting services
    3. get the tool installed
    4. deliver a BPM solution
    5. show everyone how valuable that was

    This behavior creates incentives that drive the spending of the vendor company… incentives that prevent the development of the tool that Phil is calling for.  The tool that Phil is calling for can be sold that way, but it shouldn’t.  The value of a tool that everyone can use comes when everyone uses it… for a thousand little things.  If the BPM solution cannot be installed until there is a big project, then you have a HUGE barrier to getting it installed.  Vendors have to focus on that barrier.  Unfortunately, that means taking away focus from making those “thousand little workflows” work. 

    Second problem… one visual language to rule them all

    There has been a huge investment over the years in BPMN and in BPEL and, most recently, in the ability to automatically translate BPMN models to BPEL models that, then, produce code.  This is an interesting problem, but one that probably does not need to be solved… at least not right now.  Unfortunately, it is compelling and technically interesting, so it takes up mindshare of the BPM researchers focusing on creating automated models of business processes.  This is a problem because the future depends on creating a large number of small solutions to automate “Excel over e-mail” workflows.  Solutions of that size are mostly people oriented, and don’t require complex modeling languages.  In fact, for business users, they don’t require ANY modeling languages. 

    And so we spend tons of time, perfecting a visual language that only the folks in the IT unit can use.  We are solving a problem, for sure, but it is akin to restacking the deck chairs on the Titanic.  If there is a big problem, and we don’t work on it, what does that say about us?

    My suggested solution – business and technical

    There is a way out of this conundrum.  It involved two key changes.  One is to change the business model of the vendor companies themselves, and therefore to change the software that they develop.  (That’s right, I’m starting with the business model.  Who knew that an EA would do that?)  The second change is to the features delivered in the software.  Serious investment against new features would need to be made in order to pull it off, but there is no scientific barrier… no technical obstacle.  It is a business problem and an investment priority problem, pure and simple.

    First off, I’ll put up an illustration. 

    image

    In this illustration, there are essentially four business scenario (labeled 1, 2, 3, 4).  For each scenario, the business user is consuming different amounts of software.  The scenarios are in order.  The goal is to capture those business people who will adopt BPM in a viral manner, essentially in this order.  No big up-front sales process.  Users pay for what they need, when they need it.  I will discuss the sales process below.  The scenarios are:

    1. Portal only – Most BPM packages include some kind of user interface, most often a web portal, that puts up a list of work items assigned to that particular user.  The portal may have other functions as well, like document sharing and simple list management.  Let’s change the paradigm.  Sell the portal (or give it away).  The user, in this scenario, is using the “non-BPM” features of the portal.  Note that the BPM capabilities are present, but just not being used.  In this case, the customer does not require a license for the BPM engine.  (They may require a license for the portal software.  I believe in integrated products, so I’d expect that the BPM capabilities would be built in to a portal product, rather than shipped as a completely new technology.)
       
    2. Use for common tasks – Most portal packages have the ability to set up a “workspace” or a “room” (welcome to “metaphor stew”) that is particularly useful for generic and common types of tasks.  These workspaces are normally focused around some form of collaboration.  For example, you may have the ability to set up a simple “article submission and approval” workspace, and it will come preconfigured with a simple workflow that allows authors to submit articles, while editors review and either request updates, or accept for publication.  Another editor may assign a particular article to a particular magazine issue.  This is good for everything from company or community newsletters to webzines to small-office publishing businesses.  The information captured is stored in an non-integrated data store (although web services can be available to allow the data to be drawn out if needed).
       
    3. Use for configured tasks – There are a wide variety of basic tasks that most companies need.  Things like “update customer information,” “update order information,” “review and update employee information,” etc.  The assumption is that this data lives in corporate systems of some kind, and that an adapter must be written to make it available to the web application, but that is all.  A developer would write the adapter, but the product would be shipped with about two-dozen basic adapters from which a developer can crack open the code, make a few changes, and run.  The BPM product would also ship with 500+ mini-applications, ready to go, requiring only a configured data adapter to be written. 

      Of course, many companies surround these types of basic tasks with business rules, so the mini-apps must be built in a way that it allows for configuration.  In this scenario, the requirements for configuration happen to match the options built in to the mini-application.  A developer would make these configuration changes.  When a business user wants to use this level of integration, they need to purchase a license for the BPMS.  They get the modeling interface as a result.
       
    4. Use for custom tasks – when the mini-applications won’t meet your needs, or they need especially complicated information adapters to be built, you have entered this scenario.  This is the most complicated scenario, requiring the most sophisticated BPMS software.  In this scenario, a developer can start from scratch or from a collection of the “mini-applications” and can build a complete solution from there.  The curious thing is that most existing BPMS products already handle this scenario through rich technology (except most products do not provide more than a few sample mini-applications to start from, and mostly they are not written to be configurable so that you only have to change out data adapters).
       

    The beauty of building a BPM package from this viewpoint is that this process of adoption mirrors the way that existing “Excel and e-mail” solutions have come into existence.  Most  businesses follow this bottom-up path already!  It is familiar, if not consciously so, and that makes the sales process much easier. 

    The (new) sales model

    Give the portal package away for free, or build the BPM engine into a successful portal package and get it into businesses by sending out a “new version” of the portal software.  Make the upgrade painless, to the point of being trivially easy.  The idea is to make all of the pre-packaged common task applications available to business users, as quickly as possible.  Also, make sure that they can see the list of mini-applications that they can use if they are willing to spend money and get their IT department to write some adapters.  Every common app and every mini-app will have a demo video available on your company web site, with links built into the portal product to allow for discoverable marketing.

    When the customer’s IT dept want to build their first few adapters to internal data, let them do it for free.  Don’t require a license until the adapter is being used more than 30 times a day.  Even then, let it be a nag to the IT and business users for some period of time.  The license is simply added to the running system and the nag goes away.  Make it easy to click the nag to request the attention of your company’s sales team.

    When the customer wants to configure custom business rules or modify the mini-applications, offer really good documentation and then offer consulting services.  Many companies will buy the consulting services.  Others won’t.  Don’t limit the success of your product to those companies that are willing to pay for consulting services.  

    Mind the Gap

    So what do BPMS vendors need to build in order to bring this approach to life?  Where should they focus?

    1. Integrate with a successful portal product.  If you don’t have one among your company’s product stack, find a package from another vendor that is successful and offer to embed your BPM engine into it for free distribution.  This has to be the most important, and therefore, first thing you do. 
    2. Create twenty-five or more “common task” apps, with prebuilt workflows and local data management.  Out of the box solutions.  Create a list of a few hundred uses for those common task templates.  Modify the process that a portal user goes through so that they will have the right to select one of these solutions. 
    3. Create a stripped down version of your “process state” viewer for the free version of the product.  This is used to track those common task workflows.  
    4. Create a taxonomy of data adapters that don’t overlap and from which you can build 500 mini-applications.  (This requires a little information architecture.)   Build sample adapters on top of common enterprise packages for practice… systems like SAP, Seibel, Dynamics, Oracle, etc.  Ship the samples.
    5. Create 500 mini-applications that meet actual business needs.  Poll your customers to find as many different specific situations as you can.  Then write a mini-app to match.  Get your customers to write a few, and get partners to jump in as well.
    6. Document the mini-applications and make them available to all customers.  Even better, create your very own iTunes-type of store for your partners to sell their mini-applications on.  Make sure that the repository (or store catalog) is automatically called from within the portal product to help your customers find the “newest, latest, and greatest” mini-application to solve their problem. 
    7. Get 20 ‘early adopters’ to put in your ‘upgraded’ portal application with BPM installed.  Work with business customers in those locations to get them to set up 50 installations of free common tasks.  Write down success stories.  Use them to market the heck out of the free side of your application.
       

    Some BPMS vendors are VERY close to this already.  They may have some horizontal sample apps but no mini-applications.  They may have integrated with a successful portal.  These are the vendors that are the closest to success… the closest to meeting Phil’s challenge.

    Last word

    I heard many presentations at the BPM conference.  Not every vendor was represented, but of the few that were, they were still offering software to the IT users, not to the business.  In order words, no one was focused on actually solving the problem. 

    This post is an open invitation: go fish. 

  • Inside Architecture

    Who among us uses the EABOK?

    • 4 Comments

    Know what doesn’t come up in conversation all that often?  The EA Body of Knowledge document, created by MITRE.  Perhaps it is because the document really isn’t used in the commercial settings, or perhaps it is viewed as an overlap of TOGAF (which it isn’t).  Or perhaps, with no one actively promoting it, there is no awareness of it?  I’m not sure the reasons, but the document does exist. 

    If you are interested in taking a look, you can find the EABOK at the following link:

     http://www.mitre.org/work/tech_papers/tech_papers_04/04_0104/04_0104.pdf

    I will be looking over the EABOK in the coming weeks, looking at things like

    • Who wrote it and who will keep it up to date?
    • How does the book reflect the evolving field of Enterprise Architecture
    • What organizations use the document, and how is it used?
    • Who is required to read it and learn it?  What value would they get out doing so?

     

    If you are familiar with the EABOK, and would like to help me to understand the answers to these and other EABOK questions, please contact me.

  • Inside Architecture

    Enjoying the BPM 2010 Conference

    • 1 Comments

    The field of Business Process Management is not a huge field, but I believe it to be an important one for empowering the transformation of businesses.  As an Enterprise Architect, my mission is to accelerate that transformation.  Therefore, to be aligned to my own mission, I support the increased use of practices and technologies that remove obstacles to business agility.  Business Process Management is one such set of practices and technologies.  (There are others, of course).

    BPM2010-Art-w-logo3

    The BPM2010 conference is a primarily research-based conference steered by luminaries that include  Wil van der Aalst, the author of the Workflow Patterns and the YAWL system.  Dr. Michael zur Muehlen of Stevens Institute of Technology found me on the blogosphere and asked me to come and present, which I did.  I consider myself to be fortunate to be in the presence of people who are as accomplished, intelligent, and visionary as the presenters at this conference.  This is the first time that this conference is in the US, and it won’t be back for at least a couple more years.  It is a shame that the US is so far behind in helping to develop the science of BPM.

    The keynote on the first morning, from Phil Gilbert of IBM (formerly of Lombardi) makes the case that the future of BPM is to embrace the cloud.  In addition, he makes the case that we will see the democratization of business process management and the disintermediation of the “experts.” 

    The notion of democratization is interesting to me.  I look forward to that possibility.  To be honest, I don’t think we are all that close, but my mind is open.  BPM is a highly specific field, requiring considerable training and experience.  The development of layers of indirection necessary to truly hide that level of complexity is not yet in evidence.  I suspect that the abstractions will be leaky, at least for a long time.  Perhaps with the development of more “plug and play” patterns, we can empower average business people to get value out of working with the tools directly.  Not sure. 

    I tried to strike up a conversation on this idea with one of the vendor teams.  No luck.  I don’t think we are all that close.

  • Inside Architecture

    Evolving the Enterprise Business Motivation Model

    • 1 Comments

    As my readers may know, I published a metamodel for business architecture about 18 months ago in the Microsoft Architecture Journal.  Calling it the Enterprise Business Motivation Model, I based my model on a combination of a number of standard and emerging models, including the OMG Business Motivation Model (developed by the Business Rules Group), the relatively new concept of Business Capability Modeling, and the emerging work of Dr. Alexander Osterwalder.

    Since then, Dr. Osterwalder has published a successful book called Business Model Generation (which I recommend).  We have also seen a number of interesting efforts emerge, including the new focus by the Business Architecture Working Group (BAWG) to create metamodel descriptions of various business methods, starting with Kaplan and Norton’s Balanced Scorecards.  At the same time, IBM has been making headway with their Component Business Models, which I find interesting and influential. Microsoft, of course, has something comparable in our ITAP offering (formerly branded MS-Motion).  Internally, years ago, we also developed the notion of Solution Domains which map to some of these ideas.  In addition, I’ve worked with a number of companies that have expressed interest in learning about the EBMM and in using it.  Through working with these companies, I’ve been evolving my own understanding of the best way to capture some of the elements of business modeling.

    It is time for the EBMM to evolve. 

    OK, to be fair… it’s been evolving all along, albeit quietly.  I created version 2.0 of the EBMM over a year ago (June 2009).  However, as I re-address this space, and start to bring in more formal business methods, I’m looking to evolve each of the core models within the EBMM.

    Over the course of the next couple of months, I will update and publish each of the core models of the EBMM v3 along with changes and some ideas for how a business architecture team can use these updated models in their work.  Each of the published updates will be “draft” form, and I’ll be seeking feedback from the community on changes that you feel would be valuable. 

    I look forward to your feedback.

    [nmalik – edited 9-15]

  • Inside Architecture

    Assumptions under a Zachman Framework presentation

    • 5 Comments

    I am writing this blog post while I am listening to a teleconference from Sam Holcman, founder of the EACOE, friend of John Zachman, and a leading proponent of his own methodology for using the Zachman Framework.  It should be no surprise to folks who read my blog that I have a love-hate relationship with the ZF.  I love the fact that John Zachman led the way with a great start on understanding the key elements of enterprise architecture.  I hate the resistance that some of John Zachman’s followers have expressed to the idea that his original concept is in any way incomplete, or in need of further maturity.

    I kept my mind open while listening to Sam.  Full disclosure, this is the third time I’ve heard Sam give this particular presentation.  The presentation he gave is one of his core canned talks, and he gives it well.  He goes through some of the key concepts in the “Zachman philosophy” that are elemental to how he uses, and sells, his particular Zachman-based methodology.  The concepts that he goes through are interesting, because of the assumptions under them.  The concepts sound good, but if you look at the implicit message, it is fairly easy to see the flaws.

    I will describe some statements from his presentation… then I will comment on those bits.  So that I am not taking Sam’s comments out of context, I will provide background for each point. 

    Basic Concepts

    1) “There is one framework.  It is not optional.”  As his example, Sam showed the Periodic Table of Elements and used the phrase “When Mendeleev introduced the periodic table, alchemy became chemistry.”  Interesting.  Historically invalid, but that is unimportant.  The point was that the framework is a way of understanding reality… you can ignore the framework, but not reality.

    He then went on to say “Note that the framework is not optional.  You don’t have to like it, but it exists.”  Still showing the periodic table.  True for chemistry.  He then switched to a slide that shows the English Language Alphabet (“Aa Bb Cc …etc”).  “That is another example of a framework.”   The message is that you can “ignore” the alphabet but that doesn’t change the fact that everything we write, in English, is composed of things in that small set of symbols.  By extension, you can ignore the Zachman Framework, but everything in a business is composed of the elements in that small set (30 cells).

    2) He mentions the list of views (the rows in ZF) and mentions that these perspectives are independent from one another.  Sam did NOT say that these are the only perspectives that are interesting… but he later said, clearly, that the framework was right, so there’s no room for discussion about the possibility that we need fewer, or more, viewpoints (rows). 

    3) Since 1984, the framework has essentially not changed.  This is to set to point that the ZF was so well put together that, in 40 years, it has not NEEDED to be changed.  (Is something better because it is older?  See commentary below.  Note that Sam used the term “40 years” many times.)

    4) Sam made the following point very explicitly: The framework is done.  It is correct.  There is no need to change it.  We’ve been using it for 40 years (again, that number).  No changes necessary.

    Sam then spent a good bit of time discussing his methodology.  I won’t go into a detailed critique of his methodology.  I will let evidence speak to that fact: Sam has been involved in a single project within Microsoft to use the ZF in ONE business area.  It is a complex area, true, but the project has been going on for over a year.  Has it been useful?  Hard to say.  No one from the EA team is assigned full time to this project.  As of today (8 Sep ‘10), the data collected has not been loaded into our planning system.  If the methodology was good, would it have taken this long?  As Sam would say: Hmmmm…

    Now, I’m going to look at that list again, and discuss the assumptions that Sam was making, assumptions that, when revealed, provide some insight into my concerns about the Zachman Framework.

    Commentary on the assumptions under the discussion

    • “There is one framework”: I found it ironic that Sam showed an obsolete version of the periodic table of elements (looked like something from the 1970s).  As chemistry has developed, the periodic table has changed many times.  New elements were added, and additional information is usually represented.  But that is only part of why the Periodic Table of Elements is an ironic metaphor.

    In fact, the original periodic table, as published by Mendeleev, had GAPS.  There were boxes with no elements in them.  The huge innovation of the periodic table was that it indicated that specific elements should exist that had not yet been discovered.  This fact focused the research of the time and encouraged independent teams of researchers to find elements to fill those gaps.  In some sense, the ZF has that effect.  If you see blank boxes, you “assume” that a model should be created for that box. 

    However, the gaps in the periodic table were not artificial: there really was a missing element to be discovered.  The notion of a “gap” in the ZF for an enterprise (a cell with no model) is artificial and arbitrary.  Filling a ZF cell with a model is an act of creativity, not an act of discovery.  The model may not be interesting, useful, or even valid in the context of that enterprise.   

    While Sam did indicate that the Zachman Framework was at version 1.0, he did not show version 1.0 of the periodic table of elements.  That would have called direct attention to the flawed assumption that v1.0 of the ZF is correct.  Even with this slight of hand, the fallacy is not difficult to catch.  Same assumes that a framework is stable just because he says it is.  The history of the periodic table is an excellent counter-example to illustrate this point: no matter how smart you are, you are probably not right the first time.  Or even the second time.  The statement that the Zachman Framework is complete is a “bare assertion fallacy.” 

    That is not to say that the ZF is “bad.”  The concept is probably a good one (that you can use an n-dimensional table to encourage business people to consider the creation of potentially useful models).  However, it is a fallacy to assume that it is “correct and complete” with no evidence to back it up.

    • “The use of the alphabet as a metaphor”: I get it… the Elements that we capture can be atomic.  But the assumption under that metaphor is toxic.  Using the alphabet as a metaphor implies that a methodology should capture all of those atomic elements in a simple and rational way.  Is that possible?  Feasible?  Valuable? 

      If I show you this list and say: this is an example of a complete framework (of atomic elements), you may agree with me:

    Aa Bb Cc Dd Ee Ff Gg Hh Ii Jj Kk Ll Mm Nn Oo Pp Qq Rr Ss Tt Uu Vv Ww Xx Yy Zz

    But what if I showed you this list?  Is this a framework?

    Bb Cc D Ff Gg h Ii K Ll m Oo Rr T U Vv Ww Xx Yy Zz

    Everything in the second set is in the first.  If I was to analyze a sufficiently short set of English Language words, I could come up with that “alphabet” and for that sample, it would be accurate but not complete.  You and I know it is incomplete, because we know what complete looks like.  But what if we don’t know what complete looks like?  Would we recognize“complete” when we see it?  How?   

    Is the ZF complete?  Does it have the “right” set of viewpoints?  (Why is there no row for “external influencers?”)  Does it have the “right” set of interrogatives?  (Why is there no column for “how much?”)  How would we know?  (I challenge anyone to prove, using logic, that the ZF is a complete and comprehensive framework.)

    • The list of viewpoints (rows) is right:  Really?  What about RM-ODP?  The list of viewpoints in RM-ODP, an international standard for system architecture, does NOT match the set of viewpoints in the Zachman framework.  All we need to do to prove that the ZF is incomplete is to produce an example of a model that cannot be contained within it.  Here we go: I have need of a model that illustrates the connections between the people accountable for making decisions, the bodies in which those decisions are made, the customer strategies that motivate those people, and the customer needs that those strategies are motivated to address.  Since the ZF doesn’t capture customer needs, that model DOES NOT FIT in the ZF.  The ZF is incomplete.  QED (That was easy).
    • Sam repeatedly asserted that the framework has not changed “in 40 years.”  First off, so what!  The method for manufacturing vacuum tubes has not changed in 40 years either.  No one cares about that fact either.  Secondly, 40 years?  Really?  John Zachman published his framework, in the IBM systems journal, in 1987.  That is 23 years, not 40 years.  Secondly, the list of perspectives did NOT include the “planner” perspective until 1992, when the present visualization came into being.  So the ZF is not even 23.  It is, at best, 18 years old. 

    Why is this important? 

    When running for president in 2000, Al Gore exaggerated his role in “creating the Internet.” For the exaggeration, he was widely ridiculed.  Mr. Gore had a very distinguished record in the Senate, one that rivals any other American Senator, but the fact that he exaggerated his record allowed his critics to attack his credibility and thus dismiss all of his actual accomplishments. 

    Lesson of the day: It is good to highlight a strength, but the moment you feel the need to exaggerate that strength, it becomes a weakness.  Now, to be fair, this “age exaggeration” is not a weakness of the Zachman Framework… it is a weakness of Sam Holcman.  But it applies nonetheless because he is one of (few) the remaining proponents of ZF.  

    Here’s the sad thing: that exaggeration is not necessary.  The number “40 years” is not more compelling than the number “18 years” in EA circles.  EA is a very young science.  Who cares how old the ZF is?  Exaggerating its age serves no purpose, but it does bring into question the credibility of the speaker, and by association, the topic being discussed.  Exaggeration is clearly a bad strategy.  Just ask Al Gore.

    So, after listening to Sam present, for the third time, his viewpoint on the Zachman Framework, my opinion about the ZF has not wavered.  It is simple to demonstrate that the ZF is not complete.  The list of viewpoints (rows) is artificial and does not represent the wide array of opinion about what the list of viewpoints should be.  Filling an empty cell is not always useful. 

    If we examine the metaphors used to convey ZF concepts, they contradict the assertions that Sam Holcman makes when using them.  

    Sam had a shot at convincing me.  He missed. 

Page 1 of 1 (6 items)