Enterprise Architecture Frameworks: The Fad of the Century

July 2016

SegwaysSvyatoslav Kotusev, an independent researcher, continues his analysis of enterprise architecture frameworks and asks if they’re all just management fads.

Enterprise architecture (EA) is widely used as an instrument for improving business and IT alignment in various organisations across the globe. However, as I previously reported 1 2 3, successful real-world EA practices have nothing to do with popular EA frameworks. Moreover, neither specific details nor even general ideas promoted by the most widely discussed EA frameworks can be found in real organisations successfully practicing EA2. How can it be that the most widely acknowledged EA frameworks inseparably associated with the very notion of EA turned out to be essentially unrelated to real EA practices? What does it all mean? My broad historical analysis of the EA literature shows that all popular EA frameworks, including Zachman, TOGAF and FEAF, are nothing more than typical management fads aggressively promoted by consulting companies and gurus. They are useless at best, and harmful at worst. (The full version of this article can be found on www.academia.edu4)

A history of EA frameworks

The common myth shared probably by thousands of people suggests that EA, as a discipline, emerged after the publication of the Zachman Framework in 1987. However, the evidence-based historical review5 shows that the idea of EA appeared much earlier and originates from the business systems planning (BSP) methodology initiated by IBM in the 1960s. The BSP methodology provided the initial foundation for all current EA methodologies and frameworks: the notion of information systems architecture, a top-down architecture planning approach, a formal step-wise architecture planning process, as well as various diagrams and matrices for describing the architecture.

The subsequent long history of EA can be roughly separated into three distinct time periods5: pre-EA (BSP), early EA and modern EA. The pre-EA period in the history of EA lasted approximately from the 1960s to the 1980s. Pre-EA methodologies included the seminal BSP methodology offered by IBM, the analogous Method/1 methodology offered by Arthur Andersen, and similar BSP-like methodologies offered by other consultancies and gurus.

The early EA period lasted between the 1980s and 1990s. During this period:

  1. The first EA frameworks appeared including the PRISM framework in 1986 (which was sponsored by IBM among other companies), the Zachman Framework in 1987 and the NIST EA model in 1989.
  2. The term ‘enterprise architecture’ started to be consistently used.
  3. A new generation of EA methodologies appeared, including Steven Spewak’s Enterprise Architecture Planning (EAP)6 (which ‘has its roots in IBM’s BSP’6 (page 53)) and TAFIM.

The modern EA period started in the 1990s and introduced current EA frameworks including FEAF (which is based on EAP) and TOGAF (which is based on TAFIM). All these three generations of EA methodologies are essentially based on the seminal ideas of the BSP methodology and advocate very similar formal step-wise architecture-based approaches to information systems planning.

The problem with EA frameworks

As research has consistently demonstrated over the long history of EA, the practical implementation of all the three generations of EA methodologies was associated with significant problems. For instance, for pre-EA (BSP-like) planning methodologies it was found that:7 8 9

  1. Planning is very expensive and time consuming.
  2. Plans are hardly understandable, very abstract and require further analysis to be implemented.
  3. Planning is organisationally difficult to implement; plans are carried out only partially or even shelved.

The practical experience in the early EA period revealed that:10

  1. EA development efforts require too much time, money and staff.
  2. EA documentation is too conceptual, inflexible, incomprehensible and obsolete to be useful.
  3. EA-related activities are poorly integrated into the organisation; compliance to EA is often not achieved.

The main identified problems with the modern EA include:11 12

  1. Huge efforts and resources are needed to develop and maintain EA documentation.
  2. EA documentation was low quality, improperly detailed, overly complex and often outdated.
  3. EA-related activities happen in ‘ivory towers’, EA documentation is ignored. Therefore, the research has shown that all the three generations of EA methodologies required unreasonable efforts to produce an unusable documentation, which is usually ignored or shelved.

Unsurprisingly, over the long history of EA numerous authors consistently concluded that recommended pre-EA and EA methodologies are ineffective. For instance, Goodhue et al.9 (page 383) concluded that ‘the approach is too expensive, its benefits are too uncertain, and it is organisationally difficult to implement’. Lederer and Sethi7 (page 455) concluded that ‘given their great expense and time consumption, (...) findings seriously challenge the utility of the [BSP-like] planning methodologies’. ‘In summary, strategic information systems planners are not particularly satisfied with (the BSP-like approach). After all, it requires extensive resources. (...) When the (BSP-like) study is complete, further analysis may be required before the plan can be executed. The execution of the plan might not be very extensive’13 (page 76). Kemp and McManus14 (page 20) are unsure they have ‘yet seen an EA strategy that is anything other than impractical, unachievable and, even if it could be achieved, unsustainable’. Holst and Steensen15 (page 19) conclude that ‘successful EA is difficult to create based on a large part of the established and commonly accepted mechanistic inspired EA literature’. Bloomberg16 (page 1) argues that ‘EA has achieved a surprisingly paltry level of success’.

What is more important, various authors consistently concluded that problems with all the three generations of EA methodologies are fundamental in nature. For instance, during the pre-EA period Goodhue et al.8 (page 28) concluded that ‘the evidence (...) presented here strongly supports the need for a fundamental rethinking of IS planning methodologies’. During the early EA period Hamilton17 (page 81) concluded that ‘findings from the study suggest strongly that the prescriptive approach to architecture-driven planning at the portfolio level is fundamentally flawed’. During the modern EA period Gaver12 (page 10) concluded that ‘EA often doesn't work well anywhere because the problems with enterprise architecture are fundamental in nature’.

To summarise, the evidence presented above clearly shows that all the three generations of EA methodologies:

  1. Recommended essentially the same formal step-wise architecture-based planning approach.
  2. Suffered from the same practical problems.
  3. Proved impractical and fundamentally flawed.

These conclusions reveal the deceitful story of popular EA frameworks:

  1. All popular EA frameworks are based on the 50-years-old BSP methodology.
  2. The entire family of pre-EA and EA methodologies starting from BSP and ending with TOGAF is fundamentally flawed.
  3. Despite their proven impracticability all the three generations of EA methodologies were successfully promoted and sold as ‘best practices’ by various consultancies and gurus.
  4. Instead of learning from failures of the previous generation and improving methodologies, consultants merely repacked and resold the same ‘old wine in new bottles’.
  5. The only fundamental ‘improvement’ of TOGAF over BSP is the new rhetorical trick emphasising the need to ‘adapt’ the methodology before applying it, which essentially means ‘doing something else’ as I discussed previously3.

Therefore, regardless of abundant negative feedback, over almost a half of the century numerous consultancies and gurus have been making their fortunes selling the same flawed pre-EA and EA methodologies under different titles as ‘best practices’ with significant marketing efforts and simplistic rhetorical tricks. Moreover, due to the aggressive promotion the very notion of EA is currently strongly associated with EA frameworks. However, as the analysis provided above clearly demonstrates, all popular EA frameworks and their conceptual predecessors are evident marketing-driven management fads with no demonstrated examples of successful implementation. While numerous marketing whitepapers consistently positioned EA frameworks as ‘best practices’, the evidence-based research consistently demonstrated the opposite conclusions. EA frameworks essentially have no intrinsic value, except suggesting that some EA documents should be developed and used. From this perspective it becomes perfectly clear how the most ‘definitive’ EA frameworks, including Zachman, TOGAF and FEAF, turned out to be essentially unrelated to successful EA practices as I reported previously1,2,3.

The harm of EA frameworks

The insistent promotion of ineffective ‘best practices’ could hardly be harmless for organisations and society. Probably the most spectacular example demonstrating EA frameworks at work is the failure of the Federal Enterprise Architecture (FEA) programme. The FEA programme was initiated in 1999 after the enactment of the Clinger-Cohen Act in 1996, obliging the U.S. Federal Government to develop consistent architectures for all agencies to improve the usage of information systems. The Federal Enterprise Architecture Framework (FEAF)18 was developed to be the guiding EA framework for the FEA programme.

From the very beginning all the well-known EA gurus and consultancies were heavily involved in the FEA program. For instance, John Zachman and Steven Spewak were involved in the FEAF development as ‘two of many recognised leaders in architecture conceptualisation and enterprise architecture planning’18 (page 19). To the Federal Bureau of Investigation (FBI) ‘the consultant (Arthur Andersen) recommended that the bureau develop a comprehensive EA to help reduce the proliferation of disparate, non-communicating applications’19 (page 8). IBM was involved as a contractor for developing EA as well, for instance, in the Department of Defense (DoD)20. IBM’s contract with DoD was especially lucrative: ‘To develop the architecture, DoD entered into a five-year, $95 million contract with International Business Machines (IBM) in April 2002 (...). In 2004, DoD increased the contract amount to $250 million (...). As of September 2004, DoD reported that it had obligated approximately $318 million for the programme, which is primarily for contractor support’20 (page 10). Therefore, all the authors of the most prominent pre-EA and EA methodologies mentioned before were heavily involved in the planning and implementation of the FEA programme.

The FEA programme can hardly be called particularly successful. Maturity assessments of the FEA programme21,22,23, according to the FEA assessment framework, consistently demonstrated that the vast majority of federal agencies did not mature higher than Stage 2 (‘Building the EA Management Foundation’), while only a very small number of agencies matured to Stage 4 (‘Completing the EA’) and almost no agencies matured to Stage 5 (‘Leveraging the EA to Manage Change’). The official report on the status of the FEA programme to the U.S. Congress in 2002 concluded that ‘the current state of the federal government’s use of EAs is mixed, but overall it is not sufficiently mature to support well-informed IT investment decision-making’21 (page 24).

In 2003 the similar report concluded that ‘the federal government’s state of enterprise architecture management remains less than satisfactory, with little progress being made over the last two years’22 (page 52). Eventually, the FEA programme had largely failed12. ‘Most departments and agencies reported they expect to realise the benefits from their respective enterprise architecture programmes (...) sometime in the future. What this suggests is that the real value in the federal government from developing and using enterprise architectures remains largely unrealised’24 (page 64). ‘Look at all the efforts that have been launched under the idea of architecture and all the money that has been spent under the umbrella of architecture that has all resulted in unusable shelfware’, commented Paul Brubaker, one of the principal authors of the Clinger-Cohen Act25 (page 1). Unsurprisingly, Vivek Kundra, the federal CIO of the United States, argued that EA frameworks ‘are worse than useless’26 (page 1). ‘(Enterprise architects) focus on documenting the current state or what the future state should be. By the time they are done with their architectural artifact, a new technology has already killed whatever they are working on, described he26 (page 1).

The FEA programme was not a cheap one. For instance, in 2003 it was reported that ‘$599 million being spent to date on the development of architectures’22 (page 62). In 2006 ‘departments and agencies reported that they have collectively invested a total of $836 million to date on enterprise architecture development’23 (page 45). By the end of 2010 ‘literally more than a billion dollars have been spent so far on enterprise architecture by the federal government, and much, if not most of it has been wasted12 (page 52). However, the government’s wastes are its contractors’ profits. ‘Agencies reported heavy use of contractor support for developing their respective architectures’22 (page 60) and ‘$188.9 million (of the money spent) were attributed to contractor personnel’ 22 (page 67). The later report summarised that ‘the departments and agencies allocated the reported $621 million in contractor-related costs [and] architecture development activities accounted for the majority of costs - about $594 million’23 (pages 49-50). Therefore, while the U.S. Federal Government had largely wasted the taxpayers’ money, various consulting companies and gurus made enormous profits merely creating heaps of EA documentation instead of delivering any tangible results. ‘I kept pushing the person (in charge of the project), “What did we get, what did we get, what did we get?” And ultimately it ended up being this book (EA), explained Vivek Kundra26 (page 1).

Among all the U.S. Federal Government’s agencies the Department of Defense provides the most spectacular example of progressing time and money investments in EA, but getting the same unsatisfactory results: ‘despite three years of effort and over $203 million in reported obligations, DoD’s architecture remains insufficiently defined, and the way in which the department makes business systems investments decisions remains largely unchanged’27 (page 19), ‘despite spending almost four years and about $318 million, DoD does not have an effective architecture programme’20 (page ii), ‘even though DoD has spent more than 10 years and at least $379 million on its business enterprise architecture, its ability to use the architecture to guide and constrain investments has been limited’28 (page ii).

In 2015 it was reported that ‘the architecture was not effective in constraining system investments or enabling DOD to produce reliable and timely information for decision-making purposes’29 (page ii), ‘the architecture has produced limited value’29 (page ii), ‘(the architecture) was generally not effective in achieving its intended outcomes and that its usefulness in achieving benefits, such as reducing the number of applications, was limited’29 (page 16), ‘the business enterprise architecture has not been effective in meeting its intended outcomes’29 (page 17), ‘the usefulness of DOD’s business enterprise architecture in achieving various potential benefits is limited’29 (page 18) and ‘the architecture does not enable DoD to produce reliable and timely information for decision-making purposes’29 (page 28). Among the specific problems with EA in DOD the following two were mentioned29 (page 18):

  1.  ‘The architecture is overwhelming to review and is not integrated with other activities that occur throughout the remainder of the year’.
  2. ‘The architecture is a standalone effort that does not drive comprehensive portfolio and business management through the various DOD components’.

Therefore, the experience of DOD in 2015 completely supports all the previous research results initially reported in the end of the 1980s7,9 and then consistently supported by all subsequent research: pre-EA and EA methodologies are impractical since they require unreasonable efforts to produce unusable documentation, which usually ends up in ‘ivory towers’. Since FEAF was initially based on the very same ideas as all the previous flawed pre-EA and EA methodologies, it naturally proved unsuccessful as well.

As Albert Einstein famously noted, ‘insanity is doing same things and expecting different results’. Are people promoting the same 50-years-old ideas that ruined the FEA programme insane? Absolutely not. Various consultants and gurus are making their money selling whatever can be effectively sold, regardless of whether it works or not. For instance, John Zachman, the ‘father’ of EA, who previously promoted the flawed BSP methodology during his former 26-years-long marketing career in IBM, has recently acquired the Federal Enterprise Architecture Certification (FEAC) Institute30 and is now actively selling certifications and trainings in FEAF, the EA framework largely responsible for a billion dollars of wasted taxpayers’ money, invested into the FEA programme.

Members of the FEAC Institute still promote certification programmes in the very same EA frameworks representing flawed ‘best practices’. The insanity here is that the EA community generally still does not recognise EA frameworks as yet another management fad and numerous EA practitioners are still eager to get certified in some of these EA frameworks. The fact that consultants are able to sell the same worst practices under the title of ‘best practices’ for several decades, even when the truthful information is publicly available, clearly demonstrates the unlimited power of endless marketing promises and the total impotence of evidence-based common sense. This situation vividly illustrates another infamous saying: ‘a lie told a thousand times becomes the truth’.

To summarise, the evidence presented above clearly shows that:

  1. FEAF is based on EAP (which is based on BSP) and, therefore, represents the third generation of EA methodologies.
  2. The entire family of EA methodologies proved impractical and, unsurprisingly, the FEAF-based FEA programme failed as well.
  3. The problems with FEAF are identical to the well-known problems of the entire family of EA methodologies and include high costs, unusable documentation and the isolated nature of planning activities.

These conclusions reveal the horrible story of the FEA programme:

  1. The FEA programme was essentially inspired, planned and implemented by EA consultancies and gurus who promoted the most prominent pre-EA and EA methodologies including IBM (author of BSP), Arthur Andersen (author of Method/1), John Zachman (‘father’ of EA) and Steven Spewak (author of EAP).
  2. The very same EA consultancies and gurus who inspired FEA subsequently earned more than 600 million dollars as contractors for the failed programme.
  3. The ineffectiveness of pre-EA (BSP-like) methodologies have been demonstrated empirically in the end of the 1980s - 10 years before the start of the FEA programme, i.e. FEA was doomed from the beginning, its failure was predicted by research long before the program has started.
  4. The very same problems reported by researchers more than 25 years ago are now repeated in the official report to the U.S. Congress after a billion dollars of overall wasted investments in EA.
  5. Nothing in the EA discipline has changed as a result; no lessons have been learnt by the EA community from the failure of FEA since the very same gurus continue to promote the very same flawed EA methodologies as ‘best practices’.
  6. Publicly available information on the failures of EA frameworks is generally ignored, while the number of framework-certified experts is constantly growing.

Therefore, the history of the entire three-generation family of EA methodologies is the history of flagrant scams and evident marketing manipulations, when the same flawed EA methodologies were continuously promoted under different titles as ‘best practices’ over several decades regardless of plentiful empirical evidence against them. The history of EA frameworks provides an egregious example of irresponsible salesmanship harmful for everybody, except for the salesmen (probably the dissolution of Arthur Andersen after the Enron scandal is a fair redemption). If the FEA programme alone has wasted more than a billion dollars, then what are the overall world-wide amounts of money wasted in attempts to implement ‘best practices’ described in EA frameworks? The answer to this question is unknown, but must be impressive.

What does it mean for the EA discipline?

The evidence discussed in this article clearly demonstrates that the entire family of pre-EA and EA methodologies from BSP to TOGAF is fundamentally deficient. What does it mean for the EA discipline? Does it mean that EA does not work? Not at all, it only means that EA frameworks do not work and that successful EA practices are unrelated to EA frameworks as I reported previously1,2,3.

This conclusion is again not new. For instance, Periasamy31 in 1993, reported that the notion of architecture introduced by BSP was found useful, but with significant deviations from the original prescriptions of BSP. Ross et al32 reported in 2006 that business-oriented architectures are very useful, while detailed technical architectures recommended by pre-EA and EA methodologies are ‘useful as little more than doorstops’. Holst and Steensen15 reported in 2011 that successful EA practices are organic and do not resemble mechanistic ideas of EA frameworks.

John Zachman had famously noted that EA is the issue of the century. Taking into account the total figures of money wasted in attempts to implement EA frameworks. It is fair to say that while EA might still be the issue of the century, EA frameworks (including the Zachman Framework) might only be the ‘fad of the century’ - probably the most harmful fad in the history of management fads, the ‘cocaine for executives’16 (page 1). Therefore, it is my belief that the EA community should acknowledge that the entire family of EA frameworks has no relationship to successful EA practices and is only a detrimental management fad.

The views in this article are the views of the author and are his own personal views that should not be associated with any other individuals or organisations.

References

    1 Kotusev, S. 2016. 'Enterprise Architecture Is Not TOGAF.' Retrieved 21 January, 2016

    2 Kotusev, S. 2016. 'One Minute Enterprise Architecture.' Retrieved 30 June, 2016

    3 Kotusev, S. 2016. 'The Critical Scrutiny of TOGAF.' Retrieved 15 April, 2016

    4 Kotusev, S. 2016. 'Enterprise Architecture Frameworks: The Fad of the Century.' Retrieved 2 July, 2016

    5 Kotusev, S. 2016. 'The History of Enterprise Architecture: An Evidence-Based Review,' Journal of Enterprise Architecture (12:1), pp. 29-37.

    6 Spewak, S.H., and Hill, S.C. 1992. Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology. New York, NY: Wiley.

    7 Lederer, A.L., and Sethi, V. 1988. 'The Implementation of Strategic Information Systems Planning Methodologies,' MIS Quarterly (12:3), pp. 445-461.

    8 Goodhue, D.L., Kirsch, L.J., Quillard, J.A., and Wybo, M.D. 1992. 'Strategic Data Planning: Lessons from the Field,' MIS Quarterly (16:1), pp. 11-34.

    9 Goodhue, D.L., Quillard, J.A., and Rockart, J.F. 1988. 'Managing the Data Resource: A Contingency Perspective,' MIS Quarterly (12:3), pp. 373-392.

    10 Kim, Y.-G., and Everest, G.C. 1994. 'Building an IS Architecture: Collective Wisdom from the Field,' Information and Management (26:1), pp. 1-11.

    11 Kotusev, S., Singh, M., and Storey, I. 2015. 'Investigating the Usage of Enterprise Architecture Artifacts,' in Proceedings of the 23rd European Conference on Information Systems, J. Becker, J. vom Brocke and M. de Marco (eds.), Munster, Germany: Association for Information Systems, pp. 1-12.

    12 Gaver, S.B. 2010. 'Why Doesn’t the Federal Enterprise Architecture Work?,' Technology Matters, McLean, VA.

    13 Lederer, A.L., and Sethi, V. 1992. 'Meeting the Challenges of Information Systems Planning,' Long Range Planning (25:2), pp. 69-80.

    14 Kemp, P., and McManus, J. 2009. 'Whither Enterprise Architecture?,' ITNOW Computing Journal (51:2), pp. 20-21.

    15 Holst, M.S., and Steensen, T.W. 2011. 'The Successful Enterprise Architecture Effort,' Journal of Enterprise Architecture (7:4), pp. 16-22.

    16 Bloomberg, J. 2014. 'Is Enterprise Architecture Completely Broken?' Forbes  Retrieved 11 November, 2014

    17 Hamilton, D. 1999. 'Linking Strategic Information Systems Concepts to Practice: Systems Integration at the Portfolio Level,' Journal of Information Technology (14:1), pp. 69-82.

    18 FEAF. 1999. 'Federal Enterprise Architecture Framework, Version 1.1,' Chief Information Officer Council, Springfield, VA.

    19 GAO. 2003. 'Information Technology: FBI Needs an Enterprise Architecture to Guide Its Modernization Activities,' GAO-03-959, Government Accountability Office, Washington, DC.

    20 GAO. 2005. 'DoD Business Systems Modernization: Long-Standing Weaknesses in Enterprise Architecture Development Need to Be Addressed,' GAO-05-702, Government Accountability Office, Washington, DC.

    21 GAO. 2002. 'Information Technology: Enterprise Architecture Use Across the Federal Government Can Be Improved,' GAO-02-6, Government Accountability Office, Washington, DC.

    22 GAO. 2003. 'Information Technology: Leadership Remains Key to Agencies Making Progress on Enterprise Architecture Efforts,' GAO-04-40, Government Accountability Office, Washington, DC.

    23 GAO. 2006. 'Enterprise Architecture: Leadership Remains Key to Establishing and Leveraging Architectures for Organizational Transformation,' GAO-06-831, Government Accountability Office, Washington, DC.

    24 GAO. 2011. 'Opportunities to Reduce Potential Duplication in Government Programs, Save Tax Dollars, and Enhance Revenue,' GAO-11-318SP, Government Accountability Office, Washington, DC.

    25 Perera, D. 2005. 'Hula Hoop, Rubik's Cube... Enterprise Architecture?' FCW Retrieved 10 October, 2015

    26 Tucci, L. 2011. 'Two IT Gurus Face Off on Value of Enterprise Architecture Frameworks.' Retrieved 25 October, 2015

    27 GAO. 2004. 'DoD Business Systems Modernization: Limited Progress in Development of Business Enterprise Architecture and Oversight of Information Technology Investments,' GAO-04-731R, Government Accountability Office, Washington, DC.

    28 GAO. 2013. 'DoD Business Systems Modernization: Further Actions Needed to Address Challenges and Improve Accountability,' GAO-13-557, Government Accountability Office, Washington, DC.

    29 GAO. 2015. 'DoD Business Systems Modernization: Additional Action Needed to Achieve Intended Outcomes,' GAO-15-627, Government Accountability Office, Washington, DC.

    30 Zachman International. 2012. 'Zachman International Closes Acquisition of the FEAC Institute.' Retrieved 16 April, 2016

    31 Periasamy, K.P. 1993. 'The State and Status of Information Architecture: An Empirical Investigation,' in Proceedings of the 14th International Conference on Information Systems, J.I. DeGross, R.P. Bostrom and D. Robey (eds.), Orlando, FL: Association for Information Systems, pp. 255-270.

    32 Ross, J.W., Weill, P., and Robertson, D.C. 2006. Enterprise Architecture as Strategy: Creating a Foundation for Business Execution. Boston, MA: Harvard Business School Press.

       

      Image: iStock/69843605

      Comments (9)

      Leave Comment
      • 1
        Chris S wrote on 4th Aug 2016

        Would be much more convincing if the author shared his views on what does make a successful EA practice. Easy to throw rocks at the the establishment, but credible alternatives are harder...

        Report Comment

      • 2
        Alan Boyce FBCS. CTIP wrote on 4th Aug 2016

        The proponents of EA have seen their task as one of imposing the order demanded by IT on an untidy world. Unhappily the tools it has been using to impose it have themselves been subject to unruly change. EA has thus been always been in catch-up mode - hence its constant metamorphosis.
        The solution to accept the untidy world, live with the inefficiencies of experiment and incrementality, but get something done that people can see and touch.
        This, at least, is what an IT career taught me.

        Report Comment

      • 3
        Discerning Reader wrote on 5th Aug 2016

        The article begins with superficial observations and continues throughout.

        For example, the author neglects to point out that Zachmann WORKED FOR IBM and freely admits that the original framework is based on things he learned while at IBM.

        The author goes on to take Vivek Kundra's comments at face value. I defy you to ask any senior Federal technology official (off the record) what Kundra's observations are worth. The answer to his question is "Situational Awareness." What did we get?? Situational Awareness. You can't find your way out of the jungle unless you know where the heck you are. We can argue that architecture artifacts are too big and too costly, but it's irresponsible to begin major programs with no knowledge of current state.

        The author has an axe to grind with EA, US Federal EA in particular, which is fine. But readers should know there's bias in here.

        Report Comment

      • 4
        Semyon Axelrod wrote on 9th Jan 2017

        Svyatoslav,

        while I agree that current state of EA is far from being great or even good,
        I don't think you have provided enough clarity re -- what are these "problems with enterprise architecture are fundamental in nature".
        Care to elaborate the "fundamental" part?

        thanks in advance

        Report Comment

      • 5
        Svyatoslav Kotusev wrote on 16th Jan 2017

        Three fundamental problems with EA frameworks are these (they are repeated multiple times in the article):
        1) Huge efforts are needed to develop and maintain EA documentation recommended by EA frameworks
        2) EA documentation recommended by EA frameworks turns out overly complex, unfit for purpose and often gets outdated
        3) Steps recommended by EA frameworks can hardly be integrated with other organisational processes, as a result EA documentation is not used for planning, ignored and shelved

        When I say that these problems are fundamental in nature, I mean this:
        The essential recommendations of EA frameworks cannot be successfully implemented in an effective manner even by experienced, skilled and motivated architects, regardless of how well these recommendations are executed.
        For instance, there are no practical ways to fill 30 or even 15 cells of the Zachman Framework. There are no practical ways to describe enterprises like buildings or other engineering objects as suggested by John Zachman. There are no practical ways to develop all or even half of the documents recommended by TOGAF. There are no practical ways to follow ADM steps in an iterative manner as recommended by TOGAF.
        Recommendations of modern EA frameworks and their earlier predecessors (BSP, IE, EAP, etc.) simply do not resemble effective IS planning in any real sense, while successful EA practices are completely unrelated to the actual recommendations of these EA frameworks.

        Report Comment

      • 6
        Sankarson Banerjee wrote on 13th Feb 2017

        I have been involved in multiple such efforts, and wholeheartedly agree. I've never managed to get to a state where EA is well defined and can be used for projects that are now better; all the effort goes into building a good EA itself. This gives practitioners and project participants warm fuzzy feelings, but does little to improve any business outcome. The problem is greatly exaggerated in a world where IT projects are getting smaller and faster, leading to even faster obsolescence of the EA artefacts.

        Report Comment

      • 7
        Leo Lusicic wrote on 22nd Feb 2017

        I have also been involved in a number of EA projects (since BSP times) and we usually managed to "get there", means achieve expected business results.
        I understand author’s comments and critics, and if I would not have mostly good experience, I might mostly agree with him. However I would argue, that implementing an EA framework – whichever you choose – for a fairly complex system – is always better then not implementing any. Then you are left in a space of “knowledge”, “experience”, “feelings”, “powers” etc, without a tool, that can help you communicate fundamental business needs throughout an enterprise (horizontally and vertically) without unnecessary biases, and having in the same time an “agile” paradigm requirements, is the best road to a “disaster faster”.
        I have used BSP, Zachman and TOGAF, and all have been proved as highly efficient as long as we followed the major advice they all emphasize: “take from me and apply only what make sense to a scope, domain, business needs etc. “.
        On the other hand, using a framework (any) strictly “by the book”, what sometimes is required by zealous advocates, could be a good road toward “analysis paralyses”.

        Report Comment

      • 8
        Mike Robison wrote on 1st Mar 2017

        Svyatoslav, Zachman is not a framework- it is an ontology of an architecture, so it is not right to lump it in with the rest of the frameworks. Also, at the end of the day, a framework is just an language and generally, humans use language to communicate. If communication is not happening, how often do we blame the language? A framework just allows everyone to agree on what they are talking about. To criticize the frameworks rather than the rigor or lack thereof is misleading, rather like blaming a screwdriver being used as a chisel for poor results. As the old saying goes, it's a poor workman who blames his tools! If the framework is applied as it was intended and used in a "fit for purpose" manner to ensure the business understands what it's strategic goals are and what tools and resources it has on hand to get there, then it is a useful tool. If the business doesn't understand the framework, how it is used and fails to only develop the useful and necessary architectures, then that is not a framework issue. When an architect designs a house, they usually only develop the drawings and data required to actually get the house built- anything more or less than what supports that end goal is not needed and detracts from the process. It's the same for EA.
        Finally, it would be helpful if you presented your solution to the issue, rather than just throwing rocks, as others have noted. It's easy to tear something down, but much harder to build anew. How would you fix this problem?

        Report Comment

      • 9
        Andrew Markwell wrote on 10th Oct 2017

        You can't simply look at EA frameworks in isolation of the rest of the organisation.

        1) EA practices are not well established because they are OPEX roles, but organisations keep trying to capitalise them by placing the resources on project funded work.

        2) EA practices are typically run out of technology, they should be run out of the CFOs office.

        3) Architects like designing new things, but do not seem to design their own practices.

        4) EA practices do not have any consultants working within them, EA is a consulting capability and hence, an EA practice needs to be operated as a consulting practice.

        5) EA frameworks are simply that, a framework, you can't implement a framework out of the box (everyone knows that) they have to be tailored to the organisation - if they could be used out of the box then where would the differentiation exist.

        But putting the above aside, the use or attempted use of EA frameworks has been abysmal, but I think it is more about having the wrong people in the wrong roles. I also agree that EA has been the primer for businesses becoming more disfunctional and systems becoming far more complex than they needed to be.

        A simply question to ask is "where are all the EAs in google, facebook, netflix, spotify?" - it's a simply answer!

        Report Comment

      Post a comment