Most Read This Week
Importance of Application Architecture
Importance of Application Architecture
By: Gordon Simpson
Jan. 20, 2003 12:00 AM
This is the first in a series of articles from the Office of the CTO at BEA Systems. As my main area of expertise and interest is application architecture, my role within the CTO's office allows me to explore how BEA's customers and products interact around applications - architecture, development, and integration..
Over 10 years ago I was "promoted" to the title of application architect and the word "architect" got me thinking. What does an application architect do? Remember, the title wasn't as in vogue as it currently is. I came up with the following definitions - they made sense at the time and still seem to today.
This article is a general introduction and not a master class. I'm going to focus on when application architecture is useful and what it gives us. The specifics of "how to" and "goodness" will be very interesting, too, but we'll have to cover that at another time.
OK, What Is It and Why Do I Need It?
In our applications world, an architect needs to create levels of design that span multiple business problems and continue to deliver appropriate behaviors as technology and business requirements evolve. The result is a framework that will enable the business applications to be reformed over time. The value of architecture is not some magic formula, but to provide a structure to support change.
Architecture can be applied in various "levels" and at various times. What follows is the basic route to success but, as with many things, your mileage may vary. What I hope you come away with is what we should be thinking about and why.
Enterprise Architecture - To Infinity and Beyond
Is that all? Oh yes! It's also good to remember that many systems developed in the '80s are still in our active inventory. So balance is required - not too shortsighted but not too much detail.
The key is to identify the business aspects that are core and the others that might change significantly. This will allow us to frame the risk when looking at the specific areas to support. With a solid business perspective, current technologies and future science can be assessed. Although new technologies might stimulate new business, technologies are the tools, not the goal - business is the key.
The results should support business growth or shrinkage, and replacement of application and technology components over time. Change is a constant - the architecture's aim is not just to withstand it but also to enable it. The exact structure is not important but the focus must be correct and the framework must be appropriately flexible to evolve. The enterprise architecture will also provide the framing and guidance for the next levels of architecture and design.
Technical Architecture: Infrastructure By Any Other Name Might Be Plumbing
A better goal is a set of solutions that support varying degrees of "perfection" at well-understood cost and risks. The engineering "focus" can be a powerful tool in defining the solution sets but it must be tempered with the architect's broader perspective. Success is not about technology but about supporting secure and robust business applications at the appropriate cost and time.
Domain Architecture: The Few vs The Many
The goal is still to create a long-lived framework; the specifics of the contemporary solution can be resolved by further design. Analysis of the business needs driving the architecture must include interaction with other business entities, today and in the future. The product of poor domain architecture is "silos," the focus of many a project for the last few years.
The real challenge is to support the business domain to the maximum while remaining a good enterprise citizen. Pragmatically, this is the majority of architecture so it is essential that it be done as architecture and not as a project design - the right level of detail and vision.
Project Architecture: Are You Sure We Have Time For That?
Projects are concrete, they have rigid requirements, and they require compromise. It is the role of an architect to bring the broader perspective, architecture, to the construction process. If no architecture exists, then it becomes essential for the architect to provide as much vision and breadth to the design as the timelines will allow. The role of an architect on a project is key if the resulting deployed application is to be both robust and well - behaved. While architecture is about the bigger picture, architects should be ready to get engaged on the details.
So What Next?
Reader Feedback: Page 1 of 1
Subscribe to the World's Most Powerful Newsletters
Today's Top Reads