As the world turns digital,traditional fences between social, businesses, and systems realms are progressively crumbling. That brings new challenges for enterprises governance, in particular when manifold business stakes and IT systems are concerned.
Supposedly, enterprise architecture would deal with the framing of enterprises and systems concerns into a single paradigm. Yet spirited controversies persist between bottom up and top down approaches, the former trying to upgrade the footprint of IT systems to enterprise level, the latter ready to downgrade these systems to equipment level. But dissent in that case means unfinished business: like diggers tunneling from opposite directions, both groups are to succeed together or fail together. For that to be achieved common sense dictates that both teams agree on target, with each one getting its specific orientation right.
What to look for
Issue (information systems) and circumstances (digitization of business environment) put the focus on the relationship between business processes and enterprises organization and how to capture, manage, and use information.
On that account, and not surprisingly, understandings differ between EA proponents:
- Bottom-up approaches are focused on the distinction between processes, applications, and data, overlooking key enterprise architecture concerns (a).
- Top-down approaches come with a better understanding of EA stakes but fall short of the conceptual bridge between organization and business environments (b) .
These shortcomings can be mended and approaches made to converge.
How to get there
As already noted, EA can only succeed as a discipline if systems and enterprise perspectives can be crossed, i.e if bottom-up and top-down approaches can be joined. That cannot be achieved along the outdated Process/Application/Data layers:
To begin with, the distinction between application and data, inherited from traditional programming, goes against both object-oriented design and service oriented architectures; then, processes don’t describe architectures but the way they are used.
On a broader perspective, if the impact of digitized business environments on EA is to be taken into account, data and information are to be redefined in a new paradigm, the former associated with a raw input, to be mined from the business environment and processed into the latter. It ensues that (1) data becomes irrelevant for architecture concerns and, (2) information becomes a key asset for enterprise architecture.
Merging applications and data into a logical/functional layer between business and engineering processes also critically redefines the perspective: instead of a being a collection of applications, business processes become the nexus of the architecture.
With a bottom-up EA perspective focused on business and engineering processes, a top-down counterpart has to be set from enterprise perspective that would ensure a meeting of minds around business processes.
That can be readily achieved by keeping processes as pivot between business environments and objectives on one side, enterprise organization on the other side:
Enterprise architects could then focus on the mapping of business functions to services, the alignment of quality of services with architecture capabilities, and the flows of information across the organization.
Why It Matters
A proper understanding of architecture layers is not an academic concern to be overlooked. As a matter of fact, what is at stake is the very practical purpose of EA: display of boxes and arrows or effective handling of the spindle between business processes and architectural assets. Whereas anything will do for the former, the latter cannot be achieved without a principled and effective coupling between enterprise models and systems engineering.
Further Reading
- Modeling Paradigm
- Modeling Languages: Differences Matter
- How to choose Frameworks & Methods
- Views, Models, & Architectures
- Caminao & UML
- Caminao & DoDAF
- Caminao & Archimate
- Caminao & EACOE
- Caminao & UAFP
- Focus: BPMN & EA
- Zebras cannot be saddled or harnessed
- Focus: Bounded Contexts & Open Concepts
- Event Oriented Analysis & Object Oriented Design
- NIEM & Information Exchanges
- Ontologies & Models
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- System Conceptual Thesaurus
KW,
The bottom-up / top-down description may be misguiding if it suggests a single dimension when in fact business planning is all about balancing two orthogonal perspectives: the top-down is governed by architectures, i.e assets with long life-cycles, the bottom-up is driven by business environments and competition, with life-cycles by nature shorter and transient.
https://caminao.wordpress.com/2014/10/21/processes-capabilities/
Rémy – I have struggled with the top down/bottom up problem for decades, so I find your article very interesting and informative.
See my “How low (i.e. low code) can you go?” I-II-III-IV articles at
http://www.kwkeirstead.wordpress.com
that explore various methods I have found useful in my consulting practice. (ACM, BPM, CPM, RALB, FOMM at the operational level; RBV at the strategic level).
The logical meeting place on the way up or on the way down seems to be ROI submissions and authorizations, or today, SROI.
Back in 1970, Russell Ackoff (A concept of corporate planning, Wiley-Interscience), identified three types of planning (satisficing, optimizing and adaptivizing).
It was his view that we lacked the wherewithal at the time to do “adaptivizing planning” and this, for me, has accounted for the relatively low level of acceptance of the Resource Based View method (circa 1950).
ACM/FOMM and “3D graphic free-form-search Knowledgebases” are relatively new methods that make RBV practicable.
FOMM is not new (early 1960s) but is essential for non-subjective decision-making at Cases (i.e. tracking progress/knowing when to close a Case).
3D Kbases address the fundamental issue of “.. you cannot manage what you cannot see”.
Rémy — I define an enterprise’s architecture as the structure of its data + the structure of its processes + the interactions between the two, in terms of the enterprise’s goals and objectives. Note that in this definition, the architecture concerns itself with the _structures_ of data and processes, not the details that populate those structures. That’s what makes EA so “meta”, and is what gives it much of its (potential) power. That’s also why the architectures of even very different enterprises are so similar, even if the details aren’t.
I have identified three EA killers — conflating EA with IT, with transformation (including solutions), and with the enterprise’s strategy. The Enterprise Architect should have architectural oversight authority over all of those (with veto power), but should be directly responsible for none of them.
The health of an enterprise’s architecture (as I define it) is so critical to an enterprise’s ability to achieve its goals and objectives that it deserves its own champion and defender, who is not embroiled in direct responsibility for IT, for solutions, or for strategies. Such responsibility creates irresolvable conflicts of interest, and distracts the EA from his/her defense of, education about, and consulting about the enterprise’s architecture.
Also by my definition, data and process structures are not “layers”; they are pervasive, through all levels from ideation to instantiation (the rows in the Zachman Framework).
Although I formulated my definition of an enterprise’s architecture before happening across the ZF, the two are nicely congruent — data structures are column 1, process structures are columns 2-5, and goals and objectives are column 6. I have proposed to John A. Zachman that his Framework is actually a meta-model for enterprise architectures, and he agrees. (I also view it as a meta-ontology, but that’s a different discussion.)
For more on my EA views and prescriptions, see my LinkedIn Pulse articles, available via my LinkedIn profile — “What Is Enterprise Architecture”, “How to Start an Enterprise Architecture Practice”, and “How to Create Your Enterprise Data Schema”.