Digital Edition

SYS-CON.TV
Importance of Application Architecture
Importance of Application Architecture

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?
Simply put, architecture is big picture design. The architect's job is to do abstract structural design for a specific purpose. The goal is to ensure that the form and function of a particular structure is appropriate today and remains so throughout its expected lifetime.

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
The goal of successful enterprise architecture is to explore the entire business and define an application and infrastructure framework that has the potential of delivering workable solutions for the foreseeable future.

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
Those aspects of technology that cross business solutions, and can be framed separately, are what I think of as technical or infrastructure architecture. This area of "architecture" benefits most from the enterprise work above. The high-level framing provides a focus that is hard to synthesize out of a collection of projects. Without it there is a risk of "infrastructure for infrastructure's sake." Infrastructure tends to be the domain of the engineers and should not be focused on "the" right answer. The requirements of a good technical architecture, the diversity of applications to be supported, are such that a single right answer is unrealistic.

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
Domain architecture focuses on one area of the business and, because of its focus, results in a more specific design. Think of it as building a bank within a skyscraper. The original building architect had to allow for floors to support the weight of a vault and a large open area for the business floor. The bank architect could then work within those constraints and focus on the business needs of the branch: automated tellers, security cameras, and so on.

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?
Actually, that's a good question. By the time we get to individual projects, the development of a forward-looking framework seems a little like overkill. We need good design and hopefully that is done within the scope of an existing architectural framework. So we should really discuss the role of an architect at the project level.

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?
Hopefully this has given you a useful and pragmatic perspective on the value of architecture. You probably noticed that J2EE or Web services didn't come up. We architect applications for business needs and technology's role is a supporting one. We should consider them in our process as they might open up new business requirements. It would have been appropriate to talk about them as examples of prefabricated infrastructure, but in my experience it's not a smart idea to base architecture on contemporary technologies.
To be continued?

About Gordon Simpson
Gordon Simpson is senior director of technology in the Office of the CTO for BEA Systems, Inc. Gordon plays a key role in directing BEA's enterprise application platform strategy. He has been involved in all aspects of enterprise applications development since the mid-70s.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1



ADS BY GOOGLE
Subscribe to the World's Most Powerful Newsletters

ADS BY GOOGLE

The explosion of new web/cloud/IoT-based applications and the data they generate are transforming ou...
CI/CD is conceptually straightforward, yet often technically intricate to implement since it require...
Containers and Kubernetes allow for code portability across on-premise VMs, bare metal, or multiple ...
Enterprises are striving to become digital businesses for differentiated innovation and customer-cen...
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As au...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't com...
The now mainstream platform changes stemming from the first Internet boom brought many changes but d...
DXWorldEXPO LLC announced today that All in Mobile, a mobile app development company from Poland, wi...
DXWorldEXPO LLC announced today that Ed Featherston has been named the "Tech Chair" of "FinTechEXPO ...
Chris Matthieu is the President & CEO of Computes, inc. He brings 30 years of experience in developm...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: D...
Andi Mann, Chief Technology Advocate at Splunk, is an accomplished digital business executive with e...
In this presentation, you will learn first hand what works and what doesn't while architecting and d...
The Internet of Things is clearly many things: data collection and analytics, wearables, Smart Grids...
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitori...
We are seeing a major migration of enterprises applications to the cloud. As cloud and business use ...
If your cloud deployment is on AWS with predictable workloads, Reserved Instances (RIs) can provide ...
Disruption, Innovation, Artificial Intelligence and Machine Learning, Leadership and Management hear...
We build IoT infrastructure products - when you have to integrate different devices, different syste...
Consumer-driven contracts are an essential part of a mature microservice testing portfolio enabling ...