About the Book
Next generation Enterprise Architecture (EA) is holistically practiced over the whole enterprise and throughout the full transformation lifecycle. Activities extend past architectural design into the cross-functional reality of architectural change during detailed design and implementation, through the architectural adjustments needed to get through integration, verification and deployment, out to the architectural transformations needed to sustain operations and beyond.An architecture along with management analysis and planning with costs, schedules, risks and opportunities is only the beginning of a business transformation journey. Adjustments in the architecture and management analysis and planning are required all along the journey. An architectural design which is difficult to realize, maintain, adjust, change, improve, upgrade, replace or sustain is not a good design. An enterprise has to be engineered and managed for realization where the reality of the ability to realize and sustain the enterprise must be foreseen and addressed proactively. Just as “throw it over the wall” engineering was ended through integrated team work, "Defining Enterprise" provides the foundational definition to bring “throw it over the wall” enterprise architecture to an end. The next generation EA team is an organized and integrated team with the ability to understand and communicate how everyone and everything fits into the “big picture”.
An Enterprise as a System
Looking at an enterprise as a system reveals a totally holistic and fully integrated view of an enterprise, its people, processes, information and technologies.As a system, the enterprise can be seen as it operates in the market environment to successfully deliver on its mission and satisfy its customers and stakeholders. With the mission and goals of the enterprise system driving the focus of interest within, the basic and fundamental needs of the enterprise drive the basic and fundamental capabilities to differentiate into broad and distinct, high-level categories, based on what the capabilities are intended to do (their functionality) and the purpose they serve (their goal). This enables and assures identifying the activities (‘the workings’) and work products (‘the results’) associated with the basic and fundamental capabilities the enterprise needs and the ultimate results the enterprise expects. This process-oriented mission-centric view of an enterprise supports governance of the enterprise, enabling and enhancing operations, management and control.
Capabilities and Abilities
Capabilities are aspirational, structured things to be expected, things which are needed and can be planned. Capabilities are requirements, a specification of what is desired.Abilities are actionable, functioning knowledge and experience-based proficiencies and competencies involving people, tools and equipment. Abilities are things which people and technology can do repetitively, have experience performing, and which are, in the context of an enterprise, desired by an organization or otherwise needed to realize a capability. Resources are often shared between capabilities causing resource capacity and availability issues during the periods in time when the capabilities are realized and the resources needed must be ready, applied, committed and sufficient to meet the need. Sharing resources drives the need to align and balance all capabilities with their related abilities. To accomplish this their relationships must be established (aligned) and abilities and/or requirements continuously adjusted until the abilities can meet the requirements and satisfy the need for the capabilities (balanced). In this way all capabilities work properly in the best interests of the whole.
Working and Needs
An enterprise architecture team as with all product, service and need-driven teams, is composed of people with varying functionalities, all working towards serving a common need.Each person has a set of specific skills, abilities, knowledge and experience related to a ‘discipline’, and understands the specifics of the specific functionality which satisfies the need. Each discipline is assigned to roles with tasks, goals and objectives requiring their skill set. There are ‘working’ interdependencies (‘needs’ for work product inputs and outputs) between the ‘network’ of team members (skill-sets). It is these work product needs which form time-dependent relationships in the flow of this cross-functional work. With roles and associated work products clearly differentiated, a working integration of cross-functional activities is promoted by defining the high-level flow of work and work products of each discipline and the time-phased back-and-forth work product dependencies between team members.
Information and Insight
Conducting business and executing processes uses and produces information to provide insight into the state, conditions and workings of the business.Insight is produced and used as input to operational activities and ultimately serves to support executive, management and leadership decision making. Not all information is within the management information system, its usefulness and application also within workers and operational activities. As the quantity of people, process, information, technology and other resources increase, the need to capture, comprehend, recall and apply what is both becoming known and what is already known increases, driving the need to realize an ability to learn, understand, communicate and apply what is explicitly known. Insight-based information management enables and assures data, information, configurations, records and knowledge support knowledge management, enterprise information management, big data, business intelligence and artificial intelligence abilities beyond the intentions, goals and abilities of traditional information management.
Functional Roles and Responsibilities
Holistic enterprise architecture in its entirety, is not the job of a person. It is the job of a team and each team member has a distinct function (a role) defining what they do.Without the knowledge of how everyone fits in, and an understanding of expectations and cooperation between team members, the team will not succeed, regardless of the talent of the individuals. The enterprise as a system perspective defines managerial and architectural roles in terms of the functionality they serve so team members can understand what they do regardless of what they are organizationally called, which varies from company-to-company, organization-to-organization and job-to-job. Each team member has interdependencies with other team members and what the others do. With the knowledge of how everyone fits in, and the setting of expectations for the team, it can then organize, synchronize and function to best utilize the talent of the individual team members, maximize workflow, and maintain control with minimal management in ‘out-of-flow’ conditions when adaptability and variance is needed.
There are working interdependencies for work products between team members. Work product needs form time-dependent relationships in the flow of cross-functional work.The lower order a system function is, the more disconnects and interdependencies it has with other systems, and the less it serves the higher order needs of the other systems. All systems serving the common mission of the enterprise demands cross-functional systems be identified, understood, aligned, balanced, managed, controlled and communicated. Needs for agility and affordability demands cross-functional activities be coordinated, cooperative and synchronized further increasing needs for cross-functional communication, understanding and integration. Cross-functional dependencies must be addressed to enable and assure the functionality of all dependent capabilities. Managing and controlling cross-functional dependencies is therefore critical to managing and controlling integrated activities, and in enabling and assuring proper and thorough consideration of changes to capabilities and the resultant impacts and needs on resources and other capabilities.
Too often, enterprise architecture is considered a discipline wholly divorced from the enterprise; business processes and capabilities are not cataloged, not matched against customer, partner and supplier needs; or worse, enterprise architecture is considered the analysis phase of software development."Defining Enterprise" is not the typical enterprise architecture book helping a programmer find their way up the management ladder. Rather, "Defining Enterprise" lays out practical strategies and tactics for architecting for management purposes -- that is, designing -- the business from the perspective of capabilities and intended outcomes.Finally an approach that really does build on traditional "architecture" -- that is, of buildings and technical systems -- how do you design something when you know the components in hand and the design you want, inside and out?Likewise businesses are designed, far too often by accident. Marc lays out a practical path for avoiding those accidents.This book should be on the shelf of every executive, manager and architect.
Marc has chosen a different approach to describing EA, describing management mechanisms and roles as a means to understand how the actions described in an architecture work to create success. He starts with basic building blocks; an approach I truly appreciate. Defining what it is you expect to do to satisfy customer requirements makes eminent sense. In aligning management mechanisms and roles, Marc has given the rest of us a reason for architecture development. He also gives us a better way to delineate what is an ‘enterprise’ function, from something which is down further at the operating activity level—which contributes to the overall success, but is at a much lower level of complexity.In doing that, Marc also provides a rationale for team contributions to this same overall success. Using his approach, it is much easier to see the various roles and how they contribute in an integrated, holistic way to creating and maintaining capabilities.Marc has given us a new view of the architectural world; one which I hope will elicit a lot of comment and discussion over the coming months. We need some fresh eyes, and fresh minds in our community, and this effort is one of the new shining lights.
Many have called for the advancing of the EA discipline - yet few seem to take a disciplined approach to EA. Many define EA based on what makes most sense to them, and naturally describe it a manner which revolves around their understanding, their capabilities and their perspectives of enterprise challenges and development. Some have even been daring enough to suggest that EA should demonstrate its commitment by expressing the EA endeavor in EA based terms.Marc has taken up these challenges! He has taken a disciplined approach to describing the parts and the whole of the EA capability, used recognized systems methods to describe the EA system, and provided sound foundations on which to build and extend the EA discipline and EA profession.Marc provides an approach and a reference point for any EA, any Executive or any Enterprise Change Professional to assess their own conception, practice or interaction with those involved in managing and architecting enterprises (or parts thereof) such that they can self-assess their own knowledge and capability gaps. In this manner, Marc opens a new door to the shaping of the future of EA and hence the future of enterprises
One of the strengths of the current set of enterprise architecture frameworks, ontologies and process definitions is that it gives practitioners a common vocabulary. Unfortunately, that's where the consistency ends.Every organisation builds their own custom implementation, which can have a detrimental impact on enterprise architects, managers and executives and the companies and institutions these EA practitioners work for.What Marc has done with this book, is to provide a comprehensive, insightful, but surprisingly simple way of removing some of that inconsistency. A foundational piece of work that allows any organisation to be described in a coherent and consistent manner.What's more, the relationships between these "building blocks" of the enterprise are clearly defined, allowing these interactions and dependencies to be easily seen and understood.This is fundamentally important for architects and executives, to allow them to navigate this normally hidden complexity.
I am constantly addressing how to explain the importance and significance of the need for someone qualified and experienced in “the business” and IT, who can stand across the traditional divide between technologists and those doing equally important activities necessary to run an enterprise successfully.The confusion about what an EA does is not in doubt. Join any social media discussion and that will become readily apparent. Much debate centres on the superiority of planning “frameworks” or procedural methodologies. The EA must transcend being a generalist with the skill of knowing how “things” fit together and how tools and methods employed by SMEs are used and justified.Marc’s book does what I am looking for with a considerable degree of elan and attention to detail. I particularly like the use of hyperlinks cutting across the division by themed chapters.This book deserves to be read by anyone with a need to understand how to describe the way their organization works. It gives a sound structural basis on which to figure out what is going on in their normal operating environment and all by itself is the reason I am recommending this work.Most definitely to be included in my reading list and to be recommended to others.
In “Defining Enterprise”, Marc addresses the main problem of modern “broken” enterprise architecture – its industrialization. Thus, enterprise architects through use of this "functional" definition can speak the same language, enabling them to use and share the many repeatable enterprise architecture patterns which have been developed by the community of enterprise architects.The book addresses the fundamentals of design and the functioning of an enterprise as a system in an abstract but understandable manner to explain observed patterns and link them together. Several perspectives (architectural viewpoints) which are carefully explained in the book are universal (domain independent) and they are essential for better understanding any enterprise.I found Marc’s way of applying the systems approach for enterprises very reasonable and, I believe, that this book really advances the whole enterprise architecture world towards establishing a commonly understood methodology for a multi-dimensional and actionable architectural definition of an enterprise.Now enterprise architecture has a good chance of becoming an applied science soon.
“Defining Enterprise” goes beyond the concept of enterprise and architect, creating a systems view of both, to show a structured manner by which we can evaluate systems we are building and already deployed.Enterprises by nature are complex. By taking a systems view, they become fairly straight forward. We look for the inputs, the processes, and finally the outputs.It brings me back to John Boyd’s OODA Loop and its concept of observation, orientation, decisions and actions. Where ultimately the system view is simply put as the inputs are observation, the decisions and orientation are the processes that impact the observation, and the output is the action.Beyond simply the creation of, modification of, and management of information throughout the book and process described, overall the book is extremely well done. I could not recommend this book more. Marc shows not only a way to look at enterprise solutions in the context of a system view but also ways to bring all of that together into a logical easily recreated process for building out the views and viewpoints where software architectures live.Marc’s structured approach that allows unstructured and structured data to flow through the enterprise, is beyond amazing!
The eBook, "Defining Enterprise" by Marc Gewertz is a well thought out construct, template for analyzing the modern enterprise. It makes the internal and external views of the enterprise known with a careful and deliberate articulation of the various components or aspects that help clearly define the relationships between insights, missions, capabilities and resources, breaking each into well-defined entities.Because definition is a primary aspect of all Enterprise Architecture I find this book somewhat seminal in its clear articulation of how the enterprise can be defined.I recommend this book to all E-Architects and those who manage an enterprise because it is full of valuable insights about how to differentiate the various aspects of creating and managing enterprises, while improving processes and services, or capabilities. It also make it understood the value of being able to architect the enterprise.I particularly appreciate the articulation of major management roles and functions including the integrated aspects of the E-architect. I completely agree with, “The biggest problem standing in the way of entering the next generation of EA is the endless miscommunication and misunderstanding of EA practitioner roles and responsibilities.” This book seeks to help the practitioner understand and appreciate these roles and responsibilities, which is the first step towards fixing them.
Through my carrier I have always consumed methods and frameworks. RUP, TOGAF, Zachman, Scrum, Kanban etc.As projects, technologies, business and the number of roles evolved over time through my experiences as architect, developer, technical project leader and maintenance manager, my constant challenge has been how to communicate and address the changes I identified.This book is for me a summary of all my years of practice, and the additional areas I have not touched on yet. It makes it simple to communicate to different stakeholders what view is being taken and helps everyone to grasp what to address. It stimulates thought to connect years of experiences and more clearly identifies gaps and challenges to improve the enterprise ability by small changes with big positive impacts.My organization grew organically by changes created from the bottom of the organisation. I clearly see the book is of tremendous help for such organisations as a navigation tool to grasp the scope of changes to address. I highly recommend managers, architects and others in leading roles to embrace this view. It has helped me a lot to get better dialogues with many of my colleagues.Such views are the tool to designing and reviewing self-sustaining organisations as external changes challenge the enterprise to adapt.
Defining Enterprise - The Video
Enterprise System Diagrams
Addressing the need for a philosophical view of an enterprise in the market environment requires an adjustment in architectural and managerial perspective. Conceptualizing an enterprise from its inception through its performance as an operational entity presents a view of the enterprise as a dynamic system of functionality, serving a common need.
- Systems of Interest
- Soft System Concept Diagrams
- Lifecycle Workflow
- Cross-Functional Dependencies