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
3 comments:
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.
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 :-)
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.
Post a Comment