MenuMenu

  1. Home
  2. Data Education
  3. Data Columns
  4. The Skeptical Architect – May 2012

The Skeptical Architect – May 2012

Management perceives of architecture in many different ways. As skeptical architects, we believe architecture will not be successful and useful in business as long as the perception continues. Unfortunately, benefits and outcomes of efforts in enterprise-level architecture are difficult to show immediately. Since they are not obvious to senior management, those managers do not perceive its value. Hence, a different approach may be needed to change this perspective. In reality, enterprise architecture is fundamentally about the organization’s structure.

The value to management is best described and realized by applying models in enterprise architecture to anticipate the impact of changes in business structure or to assess damage after rapid changes in the business environment occur that require rapid restructuring. Changes in the business environment such as competition, economic downturns, social changes and new technology can alter the enterprise structure, often dramatically. Enterprise architecture can help the enterprise respond to these changes. A set of interconnected architectures developed over time, as we described in our most recent article, is most useful for assessing changes.

We provide here an example of assessing change considering the following elements: the state of business needs and requirements, the utilization of an architectural framework, the identification of sets of architectural contexts and, finally, the implications of architectural rendering.

Business Needs and Requirements

Businesses often have conditions that constrain the way they have to operate, governmental, state or local regulations, for example, which places demands on a business process. Some certain items are needed or are necessary to complete the process (i.e., raw materials; information; or certain prescribed process steps, tasks and/or actions). Describing the business need entails narratives or perspectives that are interrelated with various business conditions, which provides the business context. Such descriptions respond to these six basic interrogatives: who, what, when, where, how and why. Comments on the perceptions follow.
  1. The first perception is that enterprise architecture is an IT thing – especially for developing systems:

    Many business needs and requirements are independent of software system requirements. Consider that software systems and IT in general enable the processes of an enterprise. Also, software applications may be part of a business system in a digitized enterprise but not the whole business system. Software system requirements are identified after the business needs are known and that part of the need is a digital system. Software requirements are designed elicit, analyze, document, validate and manage software or system requirements. Enterprise architecture captures the context of systems.

  2. The correct perception focuses on business architecture and its link to IT architecture:

    We need a framework, a body of knowledge, analytics and a methodology for the business architecture. In this instance, we can take from experiences over the years with developing software to build models and architectures for constructing systems.

    Within the software system development methodologies, various approaches (Agile, Iterative, Spiral, Waterfall, Lean, Scrum, etc.) are used to capture those requirements. But, each of these methodologies entails capturing some piece of the business context to develop or enhance software that automates pieces of the business process. Describing the business need always contains perspectives that are interrelated and are associated with an appropriate business need.

    For example, Schneider-Electric located in Australia, uses an AdvantageOne methodology that encompasses the following business areas for its clients: 

    Notice the reach back into the business to connect to the need for the systems. The business analysis, as a result, deals with the focus on a business system solution, which is typical of development methodologies that must connect back into the business. While this methodology covers the business situation first, where a software solution is also required, a software design methodology is incorporated in defining, developing, and implementing the process to come up with an overall solution. However, no other business structure methodologies are provided, such as Enterprise Analysis.

    Therein lies a methodology gap. Business analysis considers the whole organization as its scope; software methodologies target detail to support the automation of some business process.

What Can You Do?

From an architecture perspective, we agree with the Zachman assertion that it is a “set of primitive, descriptive artifacts that constitute the knowledge of the infrastructure of the enterprise or organization.”

To change perceptions and increase value to management, all architects should have the following key points in common regarding enterprise architecture:

  1. Fundamentally, architecture is an engineering discipline not problem solving, but it is business solution oriented;
  2. Origins of enterprise architecture are linked with and related to the need to develop software solutions;
  3. Enterprise architecture requires some type of methodology to capture the essence of the business structure and with some analytics to apply to problems. This provides the lead for problem – solution result.
  4. Enterprise architecture requires the definition of a set of primitives in some level of detail to be useful for developing a solution; and
  5. The solution can be described in many ways, the most common being through semantic-based models.
The approach we recommended in our most recent column uses sets of linked architectures and an effective, complete set of analytical techniques to quickly respond to constant changes in the business environment. This approach has proved acceptable to business management since it confirms the elements of the organization’s fundamental structure in a meaningful way.

Share this post

Gil Laware

Gil Laware

Gil Laware is Managing Partner of Information By Design, LLC, a firm who delivers business performance solutions for strategic management of organizations. He has 30 years of consulting and industry experience with Fortune 50 companies with experience in manufacturing, transportation, government, finance and banking services.  His range of experiences include: business and IT strategic planning; business process management, redesign and improvement; data architecture and management; data warehousing and business intelligence; enterprise architecture; enterprise resource planning, project management; manufacturing systems; and customer relationship management.

Previously, he was an Associate Professor of Computer and Information Technology in the College of Technology at Purdue University, an Associate Director for Fujitsu Consulting, Manager of Data Services for Whirlpool Corporation, Vice President of Information Services for Franklin Savings Bank, held various managerial and consultative roles with the IBM Corporation, and was President of Management Support Systems.  He also provides training internationally.

Gil publishes and has authored over 30 papers including a NIST chapter that discusses the gaps that exist in the manufacturing systems software development process.  He currently serves as the Vice President of Finance for the DAMA International Education and Research Foundation (DAMAF).  He may be contacted by email at gil.laware@eanalytics.com.

scroll to top