In the second part of their article, Vasile Buciuman-Coman and Michael Chervenic explore the architecture of Dynamic Business Application after having defined a new Enterprise Framework in Part I.
there is a fundamental difference between architecting software applications and designing other engineered products. Because software works with information, and information is the “carrier” for change, then change has to be built into the system architecture at the most basic level.
The core of the proposed solution is based on two frameworks:
These two frameworks allow us to handle and coordinate changes in business operations and technical team operations effectively and efficiently. For the design process, business operations and technical team operations can be considered two distinct adaptive systems, each with their own requirements.
The authors note that:
...architecting a client-server application capable to run at the enterprise level is orders of magnitude more complex than a desktop application. The main complexity of the server-side application derives from the fact the it must support two adaptive systems, one for the technical team and one for the business team, each with their own operations and controlled hierarchy.
The architecture style of Dynamic Business Applications (dubbed Adaptive Enterprise Operating Platform -AEOP) is focused on productivity for the technical team operations, the business operations and the development team. Increased levels of productivity are reached through an entity lifecycle/event-based architecture style. However,
the EDA (Event Driven Architecture) model found in the literature is different than the AEOP event model. The EDA is built around a stream of unstructured events, while the AEOP is built around a stream of structured events that are linked together by a clear set of lifecycle templates.
After describing in great details the architecture of Dynamic Business Applications, the authors conclude:
AEOP standardizes the architecture for server-side applications, something that is missing from current IT
Technologies and architecture concepts like SOA play a minor role in this architecture. Components like BPM engines, schedulers, messaging have a clear role in this architecture, however they have very little impact on the design.
Community comments
Interview with Grady Booch and the software's "dirty little secret"
by Vasile Coman,
Very interesting ideas
by Harmen Dijkstra,
Interview with Grady Booch and the software's "dirty little secret"
by Vasile Coman,
Your message is awaiting moderation. Thank you for participating in the discussion.
Here is an interesting quote from an interview Grady Booch gave to Scientific American about software few days ago (June 17, 2008)
Software's Dirty Little Secret - An interview with Grady Booch, the Indiana Jones of computer programming
:
"Q:You say there's a "dirty little secret" when it comes to writing software. Care to share that with us?"
"A: <quote> In other disciplines, engineering in particular, there exist treatises on architecture. This is not the current case in software, which has evolved organically over only the past few decades. All software-intensive systems have an architecture, but most of the time it's accidental, not intentional. This has led to the condition of most software programming knowledge being tribal and existing more in the heads of its programmers than in some reference manual or publicly available resource.</quote>"
Very interesting ideas
by Harmen Dijkstra,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hi, I've read both papers last weekend and must say that you propose some very interesting concrete approaches to deliver on the contents of the DBA paper by Forrester. I'm eagerly awaiting part three where you promise to describe a practical implementation, as I do have some doubts as to how the containers are implemented technology wise.
Harmen