I found an article on a LinkedIn group I belong to (The Enterprise Architecture Network) about Big Data Enterprise Architecture. The author, Zak Cole, view is that Big Data is driving the way organizations make and use data quickly to drive business decisions and strategies. From this assertion Mr. Cole contends that with the correct approach enterprise architecture can help a business target the right market activities, as well as fine tune their marketing, sales and business operations.
Mr. Cole writes that enterprise architecture can help digest Big Data into highlighting areas of opportunity and potential business disruption. From using Google Analytics and social media to provide deeper insight into consumer trends as well as customizing these (and other) tools to different “views” suitable to a diverse group of stakeholders.
Mr. Cole contends that the same tools big business use to leverage Big Data, can also be used by smaller organizations putting them on par with the bigger businesses. These tools allow businesses of all sizes to gain a deeper understanding of current and past state enterprise data activity making it useful for trend analysis and make projections that influence the future state of the enterprise.
One of my areas of interests has been in model based systems engineering. Given the size and complexity of large scale systems moving from a traditional document based system to one all the artifacts are contained within a model makes sense on many levels. From a maintainability and traceability aspect models have a distinct advantage.
Still models have a ways to go. The ability to execute your model largely does not exist. And if it does, it is dependent upon what added functionalities are offered by the tool manufacturers. After reading the three Gartner articles on Application Architecture it got me to thinking that Application Architects will have the same problem with a model based approach. Whether you are building your models in UML, SysML, BPMN, IDEF, or using a framework such as DoDAF, creating models that allow for execution is difficult or dependent upon what add-ins the tool vendors offer. And most of what I’ve seen has been related to testing parametrics, constraints and requirements, not whether an application can tie together business processes and simulate code execution.
However, in my search for what is being done with executable code, I came across a paper that was presented at the 2016 49th Hawaii International Conference on System Sciences entitled “Aligning Architectures of Business and Software: Software Driven by Business Process Models and its User Interface”.
In this paper the authors propose using a business process model (BPM) to drive application software. They demonstrate how they were able to do this using BPMN (Business Process Modeling Notation) to drive a JavaFX based execution engine. During the execution of the BPMN business processes the application software needs to access and manipulates business artifacts. But BPMN does not have the comprehensive definition of business artifacts so it is necessary for the execution engine to use simple data structures such as database objects, and Java classes.
The authors still have much more to do, but this is one of the few papers I’ve found where researchers are attempting to map their model to their enterprise or application architecture.
Hoch, R., Kaindl, H., Popp, R., Zeidler, C. 2016. Aligning Architectures of Business and Software: Software Driven by Business Process Models and its User Interface. 2016 49th Hawaii International Conference on System Science.
I was recently having a conversation with some co-workers about the need to help a sponsor a align their business and IT environments and eliminate gaps and bridge their various data and business silos. Some of the solutions talked involved using models to help them with this alignment.
At some point the conversation came around to modeling their enterprise. We discussed the advantages of model driven architecture and came up with a few reasons why our sponsor might want to adopt this methodology.
- Model driven development allows for much more rapid development.
- Model driven architecture allows for a better alignment of business and IT by keeping domain experts directly involved in the development. It can be developed faster and likely have a better fit-for-purpose due to the increased feedback.
- Model driven development allows for software being able to adjust to the changing business requirements. This is possible since development takes place at a much more rapid pace.
These are just a few of the ideas we came up with. What are your thoughts?
The Gartner Group has three interesting papers entitled “Application Architecture Overview, Part 1, 2, and 3”. Each deal with looks at the scope of application architecture content and its relationship to other types of architecture (Part 1), how the roles of solution architect break down to handle the project and overall scope, and a detailed look at the various roles played by other roles (Part 3).
Overall, I found these papers interesting in that they provide a very systems engineering like analysis to job of helping the customer/sponsor define the capabilities of the system, deriving requirements from those capabilities, developing a conceptual design, finalized system architecture and a finished system.
The paper breaks down this process chain into a series of well thought out steps that make the development process easy to understand. In part 2 Garner explains how the various roles map to the parts of the development team. They then go on to explain the role of the solution architect in a great deal of depth. I like that the report focuses on the need for the solution architect to create repeatable logical standards and guidelines (solution patterns) and how these patterns help software developers build their products. The Open Group has referred to these as architectural patterns in their TOGAF documentation, but not done nearly as good a job as Gartner in explaining their relevancy to solutions architecture.
In part 3, Gartner focuses on roles of the solution architect and the application architect. The paper breaks down both the scope and the role of the solution and application architect within a project, where they may over lap and where they are distinctly different.
Part 3 goes on to examine types of projects and how these work within the boundaries of size relevant to the need and scope of the solution and application architects involvement. I found it interesting that Gartner recognizes the model-driven analysis and design methodologies and their relevancy to solutions and applications development. Many projects are being too complex to be handled with Word, Excel, and PowerPoint, that model driven development has the capacity to handle that complexity.
All in all, this was an excellent summary of application architecture.
In the past few months the company I work for has been really embracing Agile as a means to change various aspects of our business. One of our core competencies is systems engineering. We are an organization with 70+ years of experience in helping our government (primarily DoD) sponsors solve some very complex problems. But the embracement of Agile is a way for us to apply newer techniques to the traditional and more time consuming methods of systems development.
At the same time, I have been reading articles on LinkedIn and other sites about bring the Agile methodology to Enterprise Architecture. As with bring Agile to systems engineering, I am still wrestling with how this can be brought to EA too.
Whether we want to admit it or not, but EA has promised much in many businesses and delivered little. It shows promise but has not delivered. Could the Agile methodology with its incremental but rapid turn around, be the thing that allows enterprise architects to quickly show a value added change?
The “just in time” and “just enough” development and delivery might be applied with success to enterprise architecture. And because the goals might be more realistic and scaled down, the quick delivery of real meaningful change might be the ticket to showing value to some EA initiatives that might otherwise never live up to their promise and hype.
I was reading a posting to a LinkedIn group I belong to, Association of Enterprise Architects, about the demonstrating the economic value of enterprise architecture. Basically the article was about the need for enterprise architecture and architects can be justified by how well it supports its two main goals – aligning the business and its operations with IT, and bridging the gap between the organization’s current state, and its desired future state.
These goals on their face, are fine, except for most enterprise architecture plans, these goals are not usually achieved in the short term. The alignment of a business and its operations with IT is at best, a long term project. And as the size of the business increases it could be that success is not achieved for many years.
The problem of course is that you need to show steady progress for an organization to keep funding an enterprise architecture endeavor. The article suggested four key indicators:
Improved Strategic Planning. Since enterprise architecture often bridges the gap between strategy and implementation, which ties to one of the main EA goals of bridging the gap between an organizations current and future state, it adds a level of transparency to the strategy implementation. Many business units operate in a stove pipe that aren’t in sync with the rest of the business, but EA helps keep these units focused on their goals
Better Communication. In order to implement a new strategy you have to communicate that strategy. The enterprise architects job is to ensure that the strategy is communicated and that a means of collaboration are available to the management and employees.
Tactical Improvements. Besides improving the strategic planning process, enterprise architecture improves overall processes. It does this by looking at what is and is not aligned and uncovering areas of redundancies. By identifying these deficiencies the architects can help save an organization time and money.
Taking Better Risks. Through strategic planning the architects can better judge where an organization can safely take risks that will likely lead to some economic benefit. This is opposed to organizations without and EA initiative that will buy into a technology without fully understanding it and therefore assuming a larger risk.
As a systems engineer working primarily with DoD sponsors, I found it interesting that the reading on Canvas entitled “Introduction to the Enterprise Information Technology Stack, Course Overview and Introductions” (Figure 1), was how closely the stacks align with the Department of Defense Architecture Framework (DoDAF).
Figure 1. Enterprise Architecture Stack
Breaking this alignment down, we have a Business Architecture layer that is comprised of the business goals, objectives, strategies as well as the functional decompositions of the capabilities and the organizational structure. This is closely mapped to the DoDAF Capability Views (CV’s) and the Operational Views (OVs’). Using the DoDAF framework, the capabilities are defined and from there the operational activities and functions are derived from those capabilities.
While Figure 2 does not depict a one-to-one mapping of what is shown in Figure 1, it does show how various DoDAF viewpoints can be mapped to the business enterprise.
The Applications and Technology map well to the DoDAF System Viewpoints (SV’s). The Data/Information map directly to the DoDAF Data and Information Viewpoint (DIV’s).
Whether you are defining an enterprise in stack or through an architectural framework, it creates a blueprint that allow the various stakeholders to trace the components (applications, systems, etc) to the objectives, processes and goals they support. This allow for greater analysis than the usual stovepipe views so often seen.
Figure 2. Mapping DoDAF Views to an Enterprise