January 20, 2016 / Dennis Holinka
Topic 1 – Stack overview
This week's posts go over the Stack of Enterprise Architecture, the components that it is composed of, and related reflections in the blog.
Post 3 - Stack and Enterprise Architecture - Enterprise Engineering
EA Stack and the origin of its taxonomy has been some of the questions that architects have asked in this relatively new discipline. Enterprise Architecting or Enterprise Systems Architecting has emerged as a hybrid art and science in engineering systems. It has been said that the most complex systems are enterprises and they are the engines of our economy. It is with that context, that I provide a look into the systems engineering view of enterprise architecture and the related stack that is used to organize its logic. MIT has provided an product and systems analogy which provides an engineering insight into enterprise architecture.
It is from analogies such as this, that Enterprise Architecture can be better understood as an attempt to look at the enterprise as a form of system that needs architecting and therefore requires a stack breakdown of its conceptual parts as was described in the our first lesson. The view provides the logical insight that the architecture is just the beginning and must be carried out in the form of engineering which has parallel analogies in software engineering, product engineering, systems engineering, etc. in that each of those have architecture modeling activities that carry through into implementations, operations, and support (e.g. engineering). Many of the architecture views and models created for and in each of the Business, Data, Application, Technology (BDAT) layers of an enterprise is related to the need of providing organizing logic for design and implementation of the enterprise systematic structure (e.g. architecting) but also its operation, support, and maintenance activities (e.g. engineering). If the enterprise is a system in need of design and implementation, it will require models at each enterprise layer to represent that need. However, more importantly, it will require models that provide the other aspects of engineering. It is from this perspective we see several types of models emerging: application architecture models to represent the business logic automation structure and behavior of the enterprise's design and implementation but also roadmaps which represent the maintenance structure transitions to new structures as you would do for simpler software structures that are aging or becoming deprecated and/or obsolete by time, wear, requirements changes, or competitive forces. The application architecture roadmaps become guidance to enterprise changes as architectural artifacts to the enterprise change-transition re-engineering to evolve the enterprise because we know from the lesson that the primary purpose of describing the architecture of an enterprise is to improve the effectiveness or efficiency of the business itself.
References: https://esd.mit.edu/symposium/pdfs/papers/nightingale.pdf
EA Stack and the origin of its taxonomy has been some of the questions that architects have asked in this relatively new discipline. Enterprise Architecting or Enterprise Systems Architecting has emerged as a hybrid art and science in engineering systems. It has been said that the most complex systems are enterprises and they are the engines of our economy. It is with that context, that I provide a look into the systems engineering view of enterprise architecture and the related stack that is used to organize its logic. MIT has provided an product and systems analogy which provides an engineering insight into enterprise architecture.
Figure: Engineering parallels in products & enterprises and relationship of architecture to engineering
It is from analogies such as this, that Enterprise Architecture can be better understood as an attempt to look at the enterprise as a form of system that needs architecting and therefore requires a stack breakdown of its conceptual parts as was described in the our first lesson. The view provides the logical insight that the architecture is just the beginning and must be carried out in the form of engineering which has parallel analogies in software engineering, product engineering, systems engineering, etc. in that each of those have architecture modeling activities that carry through into implementations, operations, and support (e.g. engineering). Many of the architecture views and models created for and in each of the Business, Data, Application, Technology (BDAT) layers of an enterprise is related to the need of providing organizing logic for design and implementation of the enterprise systematic structure (e.g. architecting) but also its operation, support, and maintenance activities (e.g. engineering). If the enterprise is a system in need of design and implementation, it will require models at each enterprise layer to represent that need. However, more importantly, it will require models that provide the other aspects of engineering. It is from this perspective we see several types of models emerging: application architecture models to represent the business logic automation structure and behavior of the enterprise's design and implementation but also roadmaps which represent the maintenance structure transitions to new structures as you would do for simpler software structures that are aging or becoming deprecated and/or obsolete by time, wear, requirements changes, or competitive forces. The application architecture roadmaps become guidance to enterprise changes as architectural artifacts to the enterprise change-transition re-engineering to evolve the enterprise because we know from the lesson that the primary purpose of describing the architecture of an enterprise is to improve the effectiveness or efficiency of the business itself.
References: https://esd.mit.edu/symposium/pdfs/papers/nightingale.pdf
No comments:
Post a Comment