Thursday, July 19, 2012

Enterprise Architecture vs. Collection of Architectures in Enterprise - Presentation Summary

My presentation went well yesterday. Quite a few audience expressed interest afterwards, and some asked for a paper. I guess I can share some key points made in the presentation here. The full presentation can be found at:

Architecture Concept

·        Original definition of Architecture by Sir Henry Watton: “In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight”
·        This definition is applicable to EA as well: EA is an operative art, the EA products must direct the effective enterprise operation
    • Commodity: EA should serve all its relevant audience and stakeholders, should be consistent and understandable by them (e.g. via multiple views)
    • Firmness: EA products should be solid and practicable enough for implementation
    • Delight: EA has to be well appreciated and accepted to be adopted and be effective in implementation

What is Enterprise Architecture?

Enterprise Architecture (EA) is an enterprise blueprint with descriptions of enterprise vision, structure, and operating models. It consists of business, application, info/data, and technical architectures as sub-domains (each sub-domain can drive down further beyond EA).

EA vs. Collection of Architectures in Enterprise

·        Enterprise Architecture
    • Plan: EA consists of architecture artifacts in concert by planning ahead with a designated purpose and scope for its views
    • Content: EA is an art of creation, with core concepts serving its soul of vision, and has the sense of entirety. The level of details should be just good enough to convey the intent and to serve the purpose. It can be refined in federated manner by sub-organizations and tasks to go further
    • Cultural Fitness: EA has to be fit in its cultural environment, with global optimization in nature, so to be appreciated and accepted for implementation
·        Collection of Architecture in Enterprise
    • Architecture artifacts may be developed separately, in different timeframes, cover different level of content details, and are created from different perspectives for different purpose
    • Lack of an overall guidance for the core, the soul, and the disciplinary elements
·        Make above two work together in concert -> a balanced approach
    • Provide the essential top-down guidance and governance framework to facilitate federated EA development effectively
    • The bottom-up EA development should follow the guidance and governance framework, so to keep in concert during organic growth
·        Lessons learned:
    • EA development needs target vision as its soul, and needs core concepts as its art of creation. The common knowledge of architecture is applicable to EA
    • The federated EA development needs to be more effective -> EA vs. Collection of Architectures in Enterprise
      • Too much control will be counter-productive
      • Too much freedom can be chaotic, self-adjustment can be very costly

EA Best Practice Observation

  • Architectural Leadership - the key to success
    • Management and coordination can not replace the true leadership needs
    • The Chief Enterprise Architect needs to have solid "Architecture Creation" capabilities to lead the efforts convincingly, and be well positioned inside enterprise
    • EA should not be treated like an operational task
  • EA Stakeholder Participation
    • It needs clear target vision or work direction for stakeholders to understand what they need to do and why doing it
    • It needs clearly identify the roles and responsibilities in order to proceed for EA development and in collaboration with others
  • EA Modeling
    • Just by using an EA tool and framework, and follow some widely published EA process will not get the EA as the end products
    • EA is a creative art, it needs soul and core concepts
  • EA Lifecycle and Management
    • EA is a living art with lifecycle, the evolution of architectural vision, drivers, insight, intent, and requirements guide EA through its evergreen process
    • EA is in a complex domain of people, systems, and culture, and in a constantly changing environment. It is important to balance top-down guidance/governance with bottom-up flexibility/freedom for organic growth -> collection of federated architectures developed with discipline.
  • EA Skills
    • Bridge technical and business, with breadth and depth in knowledge
    • Creative and artistic on vision, insight, models and views with abstraction

Recommended Action Items

·        Have a target vision as the soul (e.g. in response to next generation Internet, shared services, cloud computing, Internet of things, etc.) and have the core concepts in place before EA development; EA development is not an engineering process, it is an art of creation for enterprise operation, like the building architecture for building construction
·        Enhance guidance, discipline, coordination, and governance for EA development. EA is not merely a collection of architectures in an enterprise
·        Balance the centralized guidance and governance from top-down with the flexible federated development efforts from bottom-up to be productive in organic growth, where insightful and wise decisions have to be made in the Chief Enterprise Architect level


Yan Zhao, Ph.D said...

Comments from Jay Wang:

Yan-I share many of your ideas and concepts about EA, and like your thoughtfulness about EA practices and enjoyed reading your blogs.

“EA development is not an engineering process; it is an art of creation for enterprise operation…”- disagree. I can show you that EA development needs both engineering process and art. Let me repeat your quote of “In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight”, that is, the enterprise architecture must be actionable.

An actionable EA is rigorous and complete with architectural integrity (completely traceable, no redundant or irrelevant components). To build such enterprise architecture, engineering disciplines are required in EA practices, at least in those of mines. I recognize that lack of a mature EA methodology causes many problems in EA practices since it is hard to apply engineering disciplines and processes without a methodology. For example, in solution architecture of EA, semantic model, data model, activity mode, process model, and system model must be tightly associated, which require engineering disciplines and processes, or you will get rubbishes.

About the EA vs. collection of EA discussion, the purpose of EA practice is to make an enterprise productive and cost effective, pertaining to its mission(s). Since the enterprise architecture is driven only by missions of an enterprise with some constraints, the top-down approach is a must especially for federal agencies since all components (business and system) in the enterprise must traceable to mission objectives. Bottom-up approach may be applied only at component level, but still not recommended since reverse engineering in architecture never work well.

Response from Yan Zhao:

Thanks for comments Jay. I know where you are coming from. I guess there may be some confusion between the core architecture ideas and concepts with architecture development methodology and process. I agree that as a profession, there is certain discipline to establish and to follow with methodologies and processes, which will get mature along time. The architecture products (idea, concept, and its presentation) are an art of creation, while the creation/development processes need discipline and skills that can be trained to support the talent and creativity that generate ideas and concepts.

We have noticed from many practical examples that “EA production without a soul” is not effective. This applies to construction architecture discipline as well. We all agree that "architecture must be actionable", which can be more towards reality when it has a soul and core as guidance.

Enterprise Architectures are more like city plans (with various scopes), which are in continuous evolution mode. Merely "top-down" is ideal but not practical in reality, especially with the increase in scope. The federated approach is more reasonable, where "top-down" guidance will be evolved with refinement from bottom-up components construction in phases.

It seems to me that EA practice is still far from mature yet; still need further evolution for best practice.

Yan Zhao, Ph.D said...

Comments from Bogdan Motoc

@Yan - I think you are perfectly right when mentioning the bottom-up component (although I do see Jay's concern with bringin in too much of it too).
I am an addict to organization models that are biology inspired. These models see the organization as both a self-sustaining entity as well as an agency in an ecosystem. Survival in the ecosystem requires the external facing component of EA while preserving an organization's resilience to change will require internal insight.
In my opinion (and the way I visualized the process of finding solutions) there is a constant top-down, bottom-up set of iterative waves of influences, with the final solution being in the nodes of interference of the two streams (my other professional passion - holography :) ).

Response from Yan Zhao:

Bogdan: It is good to see that different perspectives converge towards the same right direction. I am looking forward to hearing your new findings :-)

Yan Zhao, Ph.D said...

Comments from Jay Wang:

Yan, Bogdon- Thanks for sharing the idea, and the thoughtfulness you brought in the discussion. I may see the reason why the federal approach is raised and proposed, and is also nicely said. While I appreciate the thought, an unsettling feeling of a previous life about a “bottom-up” approach still bothers me. We may probably use the same term with different connotations. I would like to understand what the bottom-up approach really means from your perspective and to see an example of an architecture created by a bottom-up or federated approach from your or any practices, and I am open to that idea.

The reason I favor the top-down only approach for designing architecture is the past experience of running into stumbles in EA practices. I saw that the architecture created by a bottom-up approach was really a pile or inventory of artifacts or data without much true traceability and associations, and without clear enterprise mission objectives and measurements in scope. It was impossible to be used for quantification and optimization of the enterprise. In other words, the architecture was useless to improve the enterprise efficiency or productivity, and to guide the operations. With that, it would be interesting to see how to address challenges in building an integral architecture when its artifacts are created by two streams. (By the way, I like holograms too especially created with multiple laser beams. )

With an EA methodology, it becomes clear to me that EA practices can be more disciplined engineering activities. The top-down approach of designing enterprise architecture is achievable and sound. An iterative engineering process of building EA based on the methodology shall be structured and is preferable. I sensed that your “federated” or “bottom-up” term may be at process level and have the connotation of “iterative process of building EA”. If it is, I agree with you.

Response from Yan Zhao:

Hi Jay, "Bottom-Up" is to take contributions from what exist inside enterprise organizations, which is quite common in creating "As-Is" EA products. The federated approach has been adopted by Federal Gov. EA and other big companies I have involved with.

Also, I'd like to clarify that "Architecture" and "Engineering" are different disciplines by intrinsic.

michael john said...

Building style refers to the generally based architectural, engineering and technical applications to the design of buildings.Thanks! Look for additional posts on this topic soon.
Building Design London