• Enterprise Architecture

    Stop blaming enterprise frameworks and focus on business alignment


    Enterprise Architecture helps an organization
    realize its competitive advantage.


    “The entire purpose of enterprise architecture frameworks is that they’re supposed to let you accurately and consistently describe architectures. If they can’t do that — if they can’t describe how SharePoint and your ERP suite fit together with everything else you’re running or will want to run — then what value do they provide?” Bob Lewis commented in his CIO magazine article, “The dark secrets of enterprise architecture.”

    Bob Lewis continues with what he calls secrets, but they seem to be more opinions. Expressing that “One reason EA frameworks and methodologies fail so often is that they are, in the end, waterfall in nature.” Many of today’s frameworks did begin in the 1980s where software delivery was waterfall and the TOGAF architectural development method (ADM) at first glance may appear waterfall; however, the ADM process is a guide and TOGAF recommends leveraging the steps as they work best
    for the organization. ADM is not an immutable process that an organization must follow exactly as documented.

    The frameworks are not ‘broken.’ The difficulties that enterprise architecture (EA) is facing are not from the tools and methodologies, but with its alignment with the organization. Still seen as an IT role, enterprise architects are continually left out of key business strategy and planning sessions. The perception of the role needs to change.

    Diann Daniel defines EA in her CIO Magazine Article, “The Rising Importance of the Enterprise Architect” as “the process of aligning a business’s strategic vision with its information technology. It connects different business units for synergistic communication and collaboration, creating a more seamless customer (or end-user) experience, “

    One tool for this alignment is capability mapping; which provides a view of the enterprise that both business analysts, and IT architects could use to design current and future systems. It defines ‘what’ the business does, it does not try to explain the where, why, or how it is accomplished. It is not focused on architecting the solution as the article is trying to tell us, but aligning the organization and IT.