Start a Discussion
SOA
user-pic

What is the Key to Effective Enterprise Architecture?

Vote 0 Votes
Referencing this article on CIO Dashboard, 16 Enterprise Architecture Strategies Learned the Hard Way, as well as Adrian Grigoriu in his blog, Enterprise Architecture Matters, what have you learned is the key to effective Enterprise Architecture?

11 Replies

| Add a Reply
  • The key to effective Enterprise Architecture is not architectural. It is executive sponsorship.

    Without the funding and organizational and reorganizational power implicit in executive sponsorship, the architecture will not change.

  • An EA effort, to return value (save costs, reduce time to market, increase Enterprise agility...), provide predictability, repeatability must have a a proper EA framewor providing a common vocabulary, structure, process and best practices that should frame and guide the development.
    Most EAs end up with piles of disjoint EA artifacts that don't permit navigation and impact analysis and in the end, do not enable the Enterprise transformation.
    Also an EA limited to IT would provide just a few benefits, compared to a full EA, that starts with a business architecture and includes organization alignment.

  • I think the key is that the technical side of the fence (i.e. the architects and project managers) need to spend effort a) convincing the non technical guys holding the purse strings that a well thought out arhictecture can save money in the longer term and b) proving it to get buy in. Once all can understand the potential results and see the evidence of those results being achieved, it's a win win for all. Sadly, it doesn't seem to happen very often.

  • The key to success - Don't call it Enterprise Architecture!

    Seriously, the term "Enterprise Architecture" has become so overloaded, over used, and convoluted that I have actually been in places where the term EA was banned from usage and using the term resulted in instant loss of credibility!

  • A key, as there are many, is getting some agreement on what "enterprise" means to the organization. An EA team could be tasked to actually come up with this definition and then, as Miko's response suggests, get the necessary backing of executive to actually operate at that level. Alternatively, enterprise level capabilities could be determined by a cross-functional team first, with the creation of an EA group to perform the architectural tasks as a next step.

    The reason why this is so important is that IT work still is predominantly done in projects, and the majority of those projects have a scope that is less than the enterprise. In that culture, if all you have is a loose belief that someone needs to be looking across projects, without agreement on how far we look, and more importantly, what we do with those things that have broader scope than the project, every single item will be a painful debate.

  • In my experience, even the best-funded, well-defined enterprise architecture strategies often fall short of their goals because of poor execution. There seems to be an ever-present divide between those defining the architecture and those who are expected to implement in accordance with it.

    The key to effective EA is to fold an execution plan into the strategy and govern delivery through all stages of transformation. In other words, EA needs to become more involved in implementation.

    This doesn't sit well with those who believe in clear separation of duties between strategists and implementers, but the siloed approach has been a persistent problem for decades. Google "strategy execution gap" and you'll see what I mean.

  • Enterprise architects are the bridge between business and IT, and are expected to turn IT projects into gold. But this doesn’t happen automatically. EAs need to lay out the business case for projects, and provide a blueprint for their successful completion and integration into the business.

  • First of all I would like to applaud Tarak. I have nothing to add to his assessment of EA-waffling by most IT-vendors.

    In the wider context of management philosophy (yes philosophy ), however, there seems to be a chance for 'EA' to get conceptual ground:

    "Enterprise Architect - Role-Description

    Within the WSM-Framework for Proper Corporate Web-Usage (providing the possibility to account for governance, within the startum of Social automation),
    the Enterprise-Architect's role is markedly different from what it is in the minds
    of current IT and Business strategists.

    According to the WSM Transfer-Model, the Enterprise-Architect's task is to

    (1) detect and compile all roles, involved during the order-fulfilment course under consideration

    (2) identify the information these roles exchange, where attention is not only
    paid to order data (as by BPM-systems), but particularly on information concerning the organization of role-interaction

    (3) clarify

    (a) which role-owner is transmitting his/her volition utterance to which other role-owner, in the course of information-exchange among roles during order-fulfilment, and

    (b) whose volition execution is captured by the departmental applications, attached to roles

    (4) design a central Bill-board, capable of serving as an integration platform for information exchange required to enable self-organizing collaboration, whereby Workflow is streaming, real-time, across the Bill-board, on which the respective Workstate is constantly identified, recorded and made available to participants

    (5) enquire, which part of volition-execution cannot be integrated into self- organization, in order to capture it in terms of Control-rules of purely prohibitive (never imperative) nature. This is, how governance is accounted for

    Notice, Volition-interaction is decomposed into (1) basically self-organizing Bill-board traffic, isomporphic to the Public-Web traffic, and (2) Bill-board datatype-definition (defining Workstate space) and Prohibitive-control rules, as Add-ins accounting for governance, in Corporate Sub-Webs."

    ( www.mastering-it.com > Portal Basics > Alignment Strategy )

  • There is no silver bullet or so-called “key? to effective enterprise architecture but understanding how enterprise architecture fits into your organization culture is important and you can do some mapping to determine what works and what does not. For example, given your particular EA organization maturity, map your capabilities or products and services (e.g. deliverables) to mainstream corporate processes such as strategy, performance, change, project, budget, risk, and portfolio, etc. Examine the current deliverables as compared to those that should be there. In other words, try mapping these capabilities below to your corporate processes and then add your EA deliverables to the mapping – see what happens:
    • Aligning strategic and operational views of business
    • Driving the technology vision
    • Transforming and automating operations
    • Facilitating and governing organizational change
    • Mitigating risk
    • Overseeing investments
    • Managing the architecture
    • Integrating people, processes, and technology

    You will notice the current touch points are important but more important are those touch points and deliverables that are missing. One of the keys is understanding your current capabilities, determining the most appropriate capabilities needed to support the corporate culture and of course a proficiency roadmap to transition your EA group from one stage of the journey to the next.

  • What is the key to effective enterprise architecture? In a word – influence. I rarely see an EA team that can’t build a reasonably good architecture, but I also rarely see an EA team that can successfully drive support for even the best of architectures. The most elegant architectures are worthless unless they are widely adopted and utilized. We don’t need more elegant architecture models, we need more eloquent architects.

    Over the past few years I have asked hundreds of architects two simple questions. First: “What is more difficult - building architecture or implementing architecture?? Every single architect without exception tells me architecture is much harder to implement than to build. My second question is more telling: “Where do you spend the majority of your time?? Their answer: “Building architecture and my architectural skills.? Even though EAs clearly understand the problem, they don’t address it. Why is that? I think it is because deep down inside, they don’t want to.

    Building organizational influence is long and difficult work. It requires an entirely different skill set than architecting. The focus is on people and relationships rather than technologies and concepts. Most architects don’t feel comfortable here. Instead of acknowledging reality and dealing with it, architects try to avoid it by putting the problem someone else’s back. “EA can’t succeed without executive sponsorship.? “Someone needs to give us more authority and control.? The fact is very very few EA teams actually get anything close to this. The majority don’t even get significant support from their CIO. And yet, somehow, many succeed. How? By building personal and organizational influence.

    - Jeff Scott, Senior Analyst, Forrester Research

  • Hi Joe,  hi Forrester's Jeff

    I'm afraid, the 'enterprise architects' you are speaking of are, finally, but IT architects, and the bridging you, Joe, are addressing is but a careless projection of programming-technology onto business matters.

    Which is to say: the different modes of conceptualization in IT and Business, though by far the most important source of Business-IT misalignment, are ignored rather than accounted for.

    As pointed out in my first reply (to this Q), enterprise architects (entitled to keep this designation) are at home in Business. In IT, their counter-parts are IT-architects.

    According to my reasoning, the bridge is to link the modes of modelling of enterprise architects and IT architects: modelling in terms of (a) volition architectures and (b) threading architectures.

    Building the bridge between these two architectures is straightforward, in principle: There is a close correspondence between
    -  elements of volition utterance and programs as parts of enterprise applications,
    -  acts of volition execution and threads executed by distributed processors.

    In practice, things are more involved due to corporate power play. There are not so many CEOs interested to have their company (or mission-critical parts of it) modelled in terms of a volition architecture.

    To the effect that day dreams of IT people - sometimes nightmares of employees - go unchecked.

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT