Print Page   |   Contact Us   |   Sign In   |   Join
AEA Search
Featured Members

Journal of Enterprise Architecture Abstracts
Share |

Abstracts from the Journal of Enterprise Architecture 2016,
issue No. 1

How about Strategy? – A Survey into the Pitfalls of Strategic Alignment
By Melissa Roelfsema, Adina Aldea, Marc Lankhorst and Henry Franken

The prospects are grim for organizations that manage organizational change through a new strategy. In the Strategic Alignment survey, conducted in the second quarter of 2014, 177 managers, consultants, architects, IT specialists and others were asked about the strategic alignment efforts and experiences of their organization. This article presents findings concerning several aspects of the strategy process. Results from the Strategic Alignment survey suggest that organizations still experience significant difficulties during development and implementation of their strategies. Especially, ineffective communication and insufficient organizational capabilities are pitfalls that prevent organizations from reaching strategic alignment.

Inter-Enterprise Architecture
By 
Yan Zhao, Ph.D

This paper introduces the notion of Inter-Enterprise Architecture (IEA) in response to the current evolution of the business environment and landscape associated with the adoption of common shared services, cloud computing, and social networking. The IEA describes the context, business environment, collaboration channels, partnership opportunities, influential components and relationships across enterprises and business organizations in a selected business domain or service domain for a targeted enterprise or business organization. The IEA enables an enterprise or business organization to understand its position in today’s networked business world. Due to the open and dynamic nature of service adoption and collaboration, and the autonomy of current enterprise structure, culture, and operating environments, it is necessary to explore how a business should be architected across boundaries to effectively respond to the common service and collaboration environment. It is becoming more important for a business to be agile and able to incorporate collaboration elements across organization boundaries. If enterprise architecture is like a city plan, the IEA is more like a plan for a metropolitan area.

Enterprise Architecture Manifesto: Defining Guiding Principles
By Matt Fishbeck

This paper proposes the idea of an Enterprise Architecture Manifesto that consists of ten principles that apply across the context of enterprise architecture, business architecture, business analysis and the wider domain of business transformation. These principles take the format defined within the TOGAF 9 Specification and are written in short form to lean out any unnecessary words, examples, or intended applications and are purely generic in definition. No references have been included because there is no information that has been obtained from other sources; this proposal is a synthesis of experience derived from 20 years’ experience within the software engineering, technology, and now business analysis and enterprise/business architecture disciplines.

The History of Enterprise Architecture: An Evidence-Based Review
By 
Svyatoslav Kotusev

The conventional wisdom says that the concept of enterprise architecture (EA) originated from the pioneering work of John Zachman. He is frequently referred to as the “father” of EA and many consider the Zachman Framework to be the breakthrough that created the discipline of EA and provided the foundation for all subsequent EA frameworks and methodologies. Is Zachman’s “A Framework for Information Systems Architecture” really the seminal publication of the EA discipline? Is it really the first EA framework? Did it really profoundly influence modern EA methodologies? In order to answer these questions, in this article I describe an evidence-based history of EA and trace the origins of all essential ideas constituting the basis of the modern concept of EA.

Abstracts from the Journal of Enterprise Architecture 2015,
issue No. 3

From the Editor – About this Issue
Leonard Fehskens

Agile EA in Practice

By Boel Ohlin, Jenni Dahlkvist Vartiainen, and Eskil Swende

Architects are often criticized for being too slow when developing the overall architecture for their enterprise. When their overall architecture is finished they are often further criticized, because it is difficult to understand, difficult to use, and the quality of the architecture is not acceptable.

This article describes how these problems were solved at the Swedish Board of Agriculture (SBA). During our architectural journey we gradually learned how to work with Enterprise Architecture (EA) in a new way. The reason was a large program (ProCAP) with a lot of uncertainty, rapid changes, and strong deadlines. The solution was Agile EA.

Book Review
Composite/Structured Design by Glenford J. Myers

Reviewed by Leonard Fehskens, JEA Chief Editor

Four Questions

A Practicing Architect Asks and Answers Four Questions of Their Own Choosing

Joe Maissel, Chair and Founder of the NY Metro Chapter

AEA Chapter Spotlight - Hungarian Chapter
Tamás Virágh, Chair and Founder of the AEA Hungarian Chapter

Enterprise Architecture Metrics
By Dr. Gopala Krishna Behara and Prasad Palli

Most organizations have been driving Enterprise Architecture (EA) initiatives across the enterprise for the last few years. Successful implementation of EA is crucial for business and IT alignment. Today, there exists no tool which measures the success of EA implementation. Based on our experience in the EA consulting space, we described a model for metrics identification, objectives, metrics parameters, and their benefits in the EA context. The success of EA implementation can be measured indirectly by measuring the achievement of the objectives set for the implementation. It also depicts the details of the recommended roles and responsibilities for EA metrics measurement, communication, and reporting.

Len’s Lens - Is versus Does
Leonard Fehskens, JEA Chief Editor

There is a widespread tendency within the EA community to mix up the concepts of an organization (an identifiable structured group of people and resources) and an enterprise (an ambitious undertaking). This failure to distinguish between what something is and what it does unavoidably leads to confusing cause and effect and their respective architectures.

Four Questions

A Practicing Architect Asks and Answers Four Questions of Their Own Choosing

Robert Weisman


Talking Shop: A Conversation with Jeff Scott

Two architects talk shop and let the conversation take them wherever it will.

Abstracts from the Journal of Enterprise Architecture 2015,
issue No. 2

AEA Chapter Spotlight - Ohio Chapter
Michael Fulton

AEA Chapter Spotlight - Ottawa-Gatineau Chapter
Robert Weisman MSc, PEng, PMP, CD

This has been an exciting year with many fascinating events. Through cooperation with several other professional organizations and the University of Ottawa, the chapter was able to host or co-host quality speakers speaking on a wide range of topics relevant to enterprise architecture.

Four Questions
A Practicing Architect Asks and Answers Four Questions of Their Own Choosing

Chris Armstrong
Vish Viswanathan

Talking Shop: A Conversation with Tom Graves
Tom Graves and Leonard (“len”) Fehskens

Short Subject
The Role of Enterprise Architecture in Digital Business

By Sharm Manwani and Oliver Bossert

Enterprise architects face many challenges to be relevant to key stakeholders. The growth of digital business offers major enterprise opportunities if these challenges can be addressed. To assess best practice behaviors, an anterprise architecture survey has been created by McKinsey & Company and Henley Business School. This article introduces the survey scope and invites the JEA audience to contribute its expertise in order to develop new organizational insights.

Short Subject
The Architect Role – What Kind of Architect are You?

By Roger Evernden

Architects come from a variety of backgrounds and with diverse personalities. Does the profession attract certain personality types? How can we be more effective as architects? This article explores some of the issues.

Article
Clumping and Strategic Enterprise Planning

By Mark P. Meyers

The phenomenon known as clumping can be found everywhere in nature as most forms of animal and plant life here on earth naturally tend to cluster together for social or survival needs. This article will push that concept out towards a hypothesis under which clumping may also be a significant determining factor why some complex strategic plans are formed successfully while others fail to gain traction.

Peer-Reviewed Article
Integrating Veterans Health Administration (VHA) Business Strategy, Function, Process, and Information

By Tammy Talley, Donna Marcum, Linda Drummond, Jim McDearmon, and Ian Komorowski

The Department of Veterans Affairs (VA), Veterans Health Administration’s (VHA) use of an innovative approach to integrate business strategy, function, process, and information is a success story of collaboration. VHA leverages architecture to foster strategic IT investment planning, requirements elaboration, impact analysis, solution decisions, and business architecture products that are aligned with VHA strategy, and allow for traceability. The VHA Business Architecture Alignment Model maps strategic goals to impacted business functions and links information concepts to business processes. The Business Function Framework (BFF) describes all of the business functions performed by VHA and provides a hub for integrating business architecture components. VHA’s innovative approach supports interoperability and data sharing with partners including joint DoD/VA initiatives and the Health IT Strategic Planning guides the development of the VHA Health Segment Architecture.

Len’s Lens - Eight Ways We Frame Our Concepts of Architecture
Leonard Fehskens, JEA Chief Editor

Recent discussions about enterprise architecture have begun to distinguish between two frames or perspectives from which enterprise architecture may be considered. These two frames are typically referred to as the “verb” frame and the “noun” frame. The “verb” frame considers enterprise architecture as an activity (i.e., something we do), and the “noun” frame considers enterprise architecture as the result of such an activity (i.e., something we produce). Informal observations and analyses of a large number of conversations about enterprise architecture in many different contexts suggest that there are in fact eight distinct frames that people use when talking about enterprise architecture. These frames strongly influence our expectations and expressions of the characteristics of enterprise architecture. Different people seem to have different preferred frames, but we are often unaware of and thus rarely explicit about them, and we rarely adopt a single frame in its pure form, leading to misunderstanding and needless disagreement. This article explores these possible perspectives and uses an analogy with music to explain them.

Book Review
Misbehaving – The Making of Behavioral Economics

By Richard H. Thaler W.W. Norton & Company, 2015, ISBN: 978-0-393-08094-0
Reviewed by Leonard Fehskens

Lately, I and a few of my colleagues who share my concerns have been calling attention to three things that seem to us to be missing from too much discussion about enterprise architecture – the central role of people in enterprise, that people are autonomous and often nondeterministic, and the unavoidable conclusion that these two things pretty much preclude enterprise architecture from ever being a truly scientific or engineering discipline. It further suggests that perhaps the “secret” to making enterprise architecture work (in the sense of fulfilling its promises) is less about business and technology and more about psychology and sociology.

So it was that when I learned about this book, it went straight to the top of my “must read” list, and having read it, I feel very strongly it is well worth calling it to the attention of the enterprise architecture community.

Abstracts from the Journal of Enterprise Architecture 2015,
issue No. 1

How Far up the Tower should Enterprise Architects Climb?
By Mark Perry
 
One subject of “friendly” office banter I have sometimes encountered, particularly in larger IT companies, is centered on the view that Enterprise Architects sit in an ivory tower and add little to solution design, development, and deployment. This article aims to address that topic head - on by discussing just how far up the tower Enterprise Architects should climb in order to provide something of real tangible value.

Len's Lens - Introduction to an Editor's Series
By Len Fehskens

The conventional wisdom about Enterprise Architecture (EA) goes largely unexamined. As the community’s consensus on what we know about EA, it is taken to be more or less axiomatic by most of that community. This article introduces a series of articles exploring alternative, specifically more inclusive, ideas about EA as a way to create the foundation for a professional discipline like law, medicine, or engineering.

Enterprise Business Motivation Model (EBMM)
TRIADS™ - The Chemistry of Business Architecture Alignment
By Atiogbe Didier Koffi


This article presents an approach that tackles the number one issue faced by most organizations:the Alignment of Business and IT. We do so by presenting a Business Architecture meta-model called the EBMM TRIADS™ and its application to aligning an organization's Business Motivation, Business Strategy, Business Responsibilities, and Business Operation. Each one of the four EBMM TRIADS shares three sets of Relationships with the other TRIADs. The Relationships contained in each one of those sets impose Alignment Constraints on the types of Business Architecture elements hosted by the TRIADs. We posit that each set of Constraints represents a dimension of Alignment between two TRIADs. The number of Relationships contained in each set indicates the Strength of Alignment between the two TRIADs that share the set. Therefore, the EBMM TRIADS can provide a solid reference for a qualitative and quantitative characterization of the Alignment achieved by an organization through its existing and targeted Business Architectures.

Measuring Enterprise Architecture Effectiveness using Key Performance Indicators
By Wendy Ariane Günther and Werner Heijstek

One of the reasons why measuring Enterprise Architecture (EA) effectiveness is considered difficult, is that it may be  challenging to choose the right performance indicators. The aim of this study is to arrive at a clear overview of Key  Performance Indicators (KPIs) that can be used to measure EA effectiveness. To arrive at such an overview, we adopted a design science research approach. For data collection prior to the design, we adopted qualitative methods; a semi-structured literature review was done and interviews were held with 18 experts in the field of EA. Prior to each interview,experts were asked to fill out an input survey. The outputs of these methods formed the input for our design phase. Initial versions of our solution have been evaluated through intermediate evaluations, an interactive evaluation session, and an evaluation survey, and modified accordingly. In this article, we present the resulting Focus Framework for Enterprise Architecture Measurements (FFEAM), which can be used to measure EA effectiveness by focusing on four areas: the decision-making process, the decision-making results, program implementation, and the actual program results. This framework can be implemented through a set of 22 KPIs for EA effectiveness. We believe this framework has the potential to aid organizations in measuring the effectiveness of their EA by shifting the focus of EA measurements to the actual desired results.
 
Book Review

Ten Books on Architecture by Marcus Vitruvius Pollio
Reviewed by Leonard Fehskens

Abstracts from Journal of Enterprise Architecture 2014,
issue No. 1


Integrated Modeling of Business Architecture and Process Design with BPMN: Application to Hospitals
By Oscar Barros and Alejandro Quezada

A Business Architecture (BA) comprises different models at different levels of abstraction. At the higher levels, the business goals and architecture are defined. At the lower levels, models become more detailed for implementing the supporting information system. So, an integrated modeling approach is key for designing such architecture. The different models must preserve the alignment to the business goals between the different levels. Since existing design approaches, e.g. Model Driven Architecture (MDA), use Unified Modeling Language (UML) for modeling, the design of the architecture becomes complex and time consuming. In this paper, we present an integrated design approach for designing the Business Process Architecture that uses a generic architecture and patterns, expressed in Business Process Model and Notation (BPMN). The approach facilitates the modeling between the different levels. This has been applied in real cases in hospitals and other domains, demonstrating its feasibility and usability, reducing complexity and time for modeling. We also discuss the limitations and future work.

An Enterprise Architecture Approach to Establishing ISCMP
By Shirley Zhao

Establishing an Information System Continuous Monitoring (ISCM) Program (ISCMP) is a complex effort that touches many business lines within a large enterprise. In search of a systemic approach to breaking down this complex effort, this paper explores how an enterprise architecture framework and its method, The Open Group Architectural Framework (TOGAF) Architecture Development Method (ADM), can be leveraged to establish an ISCMP for large enterprises. It examines enterprise ISCM program elements and illustrates how these elements can be potentially addressed throughout a series of phases adapted from the TOGAF ADM method.

The author intends to bring out the enterprise perspectives and relationships around an ISCM program, hoping to evoke interest from researchers and practitioners in developing more solid and tangible steps. Such work should benefit a realistic adoption of ISCMP.

Chief Enterprise Architect as Transformational and Transactional Leader
By Dr. Gerald R. Gray

Probably as much or more than any other role in the enterprise, the Chief Enterprise Architect role requires the use of influence. Influence with peer leaders, influence among teams that do not report to the enterprise architecture function, and influence with the upper levels of organizational management as architecture is developed to meet business capability needs. This level of influence requires the Chief Enterprise Architect to have superior leadership skills. There are two archetypes of leadership: transactional and transformational. Leadership literature often suggests that one archetype is better than another. This paper suggests that there are times when the Chief Enterprise Architect will need to employ both archetypes. Some well established leadership frameworks that use these archetypes will be examined and synergized into a holistic leadership model which the Chief Enterprise Architect can apply to their leadership activities.

The Architect as a Salesman within the Enterprise
By Arvin Levine, Ph.D.

The job requirements for the enterprise architect are easily stated:  to analyze, organize and synthesize technical, organizational and process information in order to plan and guide development, adoption and operations over a long arc of time. The architect must be able, not only to understand a (technical) concept, but also to convey that understanding to the people who will decide and execute on it. An important metaphor for the architect function is as a salesman – for ideas! A good salesman takes a long-view of his customer’s (possibly unspoken) needs and becomes a partner in the realization. When an architect behaves like a salesman (in the best sense of the term), he can have deep impact and successfully introduce and “sell” concepts to an organization. In order to be successful, the architect must consider himself or herself as a salesman for the concepts and understanding that they have developed. Four steps to follow in the salesman’s approach are spelled out and illustrated in this paper. Being a salesman is not necessarily the ungentlemanly occupation eschewed by our profession. We should embrace, not shun it!

Rediscovering EA via Consensus Standards
By Thomas Mowbray, Glenn Donaldson, Brian Keller, Chad Neal, and Vasu Rachakonda

A key goal of enterprise architecture (EA) entails maturing organizations from making locally optimal decisions to making globally optimal decisions. Rather than gathering EA information to create enterprise views, an alternative approach is to gather internal experts to directly participate in global decision-making. With sufficient critical mass of expertise, the necessary enterprise knowledge will be present, as well as, the ability to negotiate consensus standards that will be implemented, because the implementers participate in the standards decisions and own the outcomes.

Journal of Enterprise Architecture Readership Survey Results – Part 2
By Leonard Fehskens

The Journal of Enterprise Architecture (JEA) conducted a survey of its readership during the Autumn of 2013. The results of the survey were uniformly positive – overall, survey participants find the JEA interesting, readable, useful and providing them with value they do not find elsewhere. This article summarizes the results of the demographic questions and the open ended comments.

Book Review
How Designers Think: The Design Process Demystified by Bryan Lawson
Reviewed by Leonard Fehskens

Abstracts from Journal of Enterprise Architecture 2013,
issue No. 4 

 

A Blueprint for Professionalization of Enterprise Architecture
By Jason Uppal

Enterprise Architecture (EA) is a relatively new profession compared to others such as project management, engineering, law and medicine. Over the last two decades, interest in EA has been steadily growing for various reasons and at the same time debate among practitioners has also been growing as what is the scope of EA, how do we measure its performance and how do we validate the value of our services and so on.   I believe it is time to ask ourselves about the evolution of the profession: 1) should we allow the profession to evolve naturally or 2) should we apply well-known design methods and let its evolution be guided by sound principles? 

The purpose of this article is to propose a straw-man model for making EA a profession and initiate discussions with a wider community that will lead to a comprehensive roadmap for doing so.

Architecture Expeditions: a Difference That Makes a Difference
By Leo Laverdure and Alex Conn, Ph.D.

Training of architects improves their architectural knowledge and skills. We know this because we test it. What we don't test is the impact this training has on the organization. Has its architectural capability improved? Has business performance improved?

Too often, the ideas learned in training simply fail to take root: individuals learn but nothing really changes. Why? Because organizations resist change.

To overcome this resistance, we must engage the organization in the change effort. In particular, how do you sign up senior management? They are looking for measurable improvements to the business and will want to see evidence. Who has done this before? What results did they get? How did they make it work? What can we learn from them? Can we make it work here?

An "architecture expedition" is a potentially valuable approach that addresses these concerns. An expedition is a topic-specific, action-focused program, lasting several months, designed to help front-line teams make rapid improvements in key performance metrics. Unlike our current, out-of-context model of training, in expeditions architects learn as they measurably improve the organization's architecture capability—and, most importantly, business results.

Expeditions have an important educational component. But rather than having instructors and learners, everyone learns from everyone. And the instructor role changes from source of knowledge (a "sage on the stage”) to expedition leader (a "guide on the side”) who coaches the participants in achieving the desired improvements.

The PRISM Architecture Framework – was it the very first Enterprise Architecture Framework?
By Roberto Rivera

This article introduces a little known architecture framework and development method called the PRISM Architecture Framework.  This framework was published to a very limited research sponsor audience in 1986.  The objective of this article is to bring this milestone achievement into the public light, as it not only is likely to be the very first enterprise architecture framework, but the results of the PRISM team research has had a far reaching influence in how we do architecture work today – and we didn’t even know it.

The Dutch State of the Practice of Architecture Principles
By Danny Greefhorst, Henderik Proper, Georgios Plataniotis

Architecture principles are the cornerstones of Enterprise Architecture and guide enterprises in their transformations. The Architecture Principles working group of the Dutch Architecture Forum (NAF) wanted to gain more insight into the current practice of architecture principles. To do this, the working group has performed a survey amongst practitioners. The survey results show how practitioners actually specify architecture principles, how they value them and what other areas of applications they see for principles. This article provides an overview of the most interesting results of the survey. In addition, it provides insights gained from a workshop that was organized in which the survey results were presented.

Book Review
fit: an architect’s manifesto By Robert Geddes
Reviewed by Len Fehskens

The applicability of ideas from conventional architecture to the enterprise is a recurring theme in discussions about enterprise architecture. Too often though, such discussions provide few insights because most enterprise architects know so little about what "real” architecture is about.

This stylish little book may be the answer to this problem.

Book Review
Beyond Alignment: Applying Systems Thinking in Architecting Enterprises
Reviewed By Richard Veryard

One of the most popular memes in Enterprise Architecture is the notion of Alignment – for example the "alignment" between business and technology.  But what is this "alignment”, and why should we care about it?

There have been many initiatives recently to explore possible interworking between Enterprise Architecture and Systems Thinking, and I have been involved in some of these initiatives myself.  So I was delighted to be invited to review this collection of papers.

The contributors represent a range of different schools of Systems Thinking, including System Dynamics, Soft Systems Methodology and Cybernetics, with several contributors featuring the Viable Systems Model developed by Stafford Beer.

Abstracts from Journal of Enterprise Architecture 2013,
issue No. 3

EAST Meeting Report
By Richard Veryard

There is a growing interest among Enterprise Architects in Systems Thinking. There are several possible reasons for this interest: 

1. The idea that Systems Thinking provides some theoretical underpinning for Enterprise Architecture and/or systems architecture.
2. 
The idea that Systems Thinking is somehow complementary to Enterprise Architecture, and that there is some kind of synergy available from putting together concepts, techniques, and practices from the two disciplines.
3. The 
idea that Systems Thinking and Enterprise Architecture are essentially doing the same things (modeling, abstraction, joined-up thinking, big picture, enterprise-as-system, etc., etc.).
4. 
The idea that Systems Thinking and Enterprise Architecture are rivals for our affections, and their respective champions are trying to show that one is more conceptually coherent, more broadly based, more solidly grounded, and even perhaps more useful, than the other.

A
Plain English Introduction to Enterprise Architecture
By Peter Murchland

One of the prime barriers to effective engagement with enterprise stakeholders is the use of language that they do not understand. This article seeks to convey the answers to questions in relation to the why, what, and how of Enterprise Architecture (EA) in plain business language.

Producing Enterprise Architecture Content that Counts
By Sally Bean

This article provides practical advice on how to make Enterprise Architecture (EA) content more relevant and actionable for organizations. It explains how, before deciding what content to produce, EA teams must create a clear picture of the purpose of EA and its contribution to activities, decision-making, and objectives. It then describes different types of EA content and all the different aspects of managing it to ensure it remains accessible, current, consistent, and relevant. A simple three-way classification scheme is presented that helps to clarify whether EA artifacts represent prescriptive designs, descriptive knowledge, or programmatic plans, and hence how those artifacts should be presented and communicated for maximum impact. The article then discusses the human and social aspects that must be considered to ensure that value is actually realized. Finally, it outlines the importance of tools and frameworks in maintaining structure and consistency of content.

Using the Component Factory Business Model to Deliver Technology Re-use
By Jeff Scott

Re-use of code, services, and other technology components promises the Holy Grail of low cost, high quality, quickly delivered, and easily adaptable systems. However, after more than a decade of theories, models, frameworks, and technologies, most IT organizations continue to be frustrated in their attempts to attain even a moderate amount of re-use.

The Component Factory Business Model represents a proven, business-driven approach to implementing a re-use program that motivates project teams to re-use existing components and contribute to building new ones without the need for senior management mandates, complicated governance structures, significant up-front investments, or complex software. It does this by helping teams focus on business value and buyer motivations instead of governance-driven compliance. This case study describes the successful implementation of a technology re-use program using the Component Factory Business Model.

Enterprise Architecture: A Courageous Venture
By Chris Potts

How does Enterprise Architecture differ from other forms of architecture? If, "architecture is architecture is architecture”* does the medium make any difference? In other words, is designing an enterprise essentially the same as designing a building, a ship, or a landscape? This article explores the most significant challenge facing the people who design enterprises, that makes it different from designing physical entities such as buildings. That challenge is founded on the fact that an enterprise is a human endeavor, and enterprise is a facet of the human spirit. An enterprise can, and does, constantly redesign itself. Enterprise Architects** must have the capabilities, and often the courage, to steer this "self- architecture” from within. Whether they are permanent employees or external consultants, they are integral to the structure they are there to design. This article explores the core capabilities that Enterprise Architects need in order to succeed.

Core Knowledge for Enterprise Architecture
By Eskil Swende

Core Knowledge for EA is a concept focusing on the most important artifacts to create a robust Enterprise Architecture (EA). The approach is based on the EA definition: "The Enterprise Architecture ensures that the enterprise as a whole is always fit-for-purpose for achieving its vision, mission, and strategies”.

That means it must reflect all known changes to the current vision, mission, and strategies, but also be fit-for-purpose to meet yet unknown changes. Therefore, the architecture must be based on the business itself and on a stable foundation that does not change when the organization or strategies change. The most stable artifact is the information resource itself, when it is properly defined and the structure is based on a normalized model of the data and information. A normalized meta-model shows how the information resource relates to the business processes and the business innovation canvas.

The goal of EA is to restructure the enterprise to become more efficient, robust, and integrated. The approach is based on experience since 1984 of creating over 100 business architectures and ongoing contacts with global EA experts learning from and being inspired by them. We strive for a shared understanding of the knowledge developed by the global experts trying to achieve a coherent EA strategy based on a Core Knowledge for EA.

Dotting the Joins: The Adverse Effects of Specialization
By Tom Graves

Specialization is often seen as the natural way to deal with the demands of real-world practice and real-world complexity: we’ll often choose specific "subject areas” to specialize in from school days onwards. Yet that choice is not without its consequences; for example, we’ll often hear about the need to "join the dots” between the different domains and disciplines and other specialisms. This article explores some of the adverse effects of specialization, and what we can do to mitigate them within our Enterprise Architectures (EAs).

Sign In
Login with LinkedIn
OR


Latest News
AEA Events

4/24/2017 » 4/27/2017
The Open Group Berlin, Germany 2017 | Smart Cities, Making Standards Work®

4/27/2017
Atlanta Chapter Meeting

5/10/2017
AEA Ohio Chapter Meeting

5/12/2017
NY Metro May 2017 Meeting

 

Join our AEA LinkedIn Group!