Why Use Architecture in a Dynamic Publishing System?
- Why Use Architecture in a Dynamic Publishing System?
- About this Article
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Why Use Architecture in a Dynamic Publishing System?
Some view learning architecture and following the necessary guidelines it imposes in an application as a daunting task. There's a constant learning curve before an individual can be called proficient in architecture. With that said, understanding why you would even bother learning architecture is a valid question.
Reasons to Learn About Architecture
There are several reasons for an organization or a developer to take the time to immerse in this thing called architecture.
The first reason behind using architecture is that it saves development time for the project by helping plan the entire application before development starts. This is because architecture in its simplest term is the mapping out and visualization of what the application is intending to do. With architecture in place, an application has the capability to discover flaws before a single line of code is written. Software studies have shown that requirement flaws captured this early can have a return on investment (ROI) in cost savings of upward to 10 times of what it would have been if caught during the designing steps of the application. One particular report illustrated in Karl E. Wieger's book Software Requirements (Microsoft Press, [cw]1999) estimated the cost to change a requirement at 200 percent more than the initial cost of building that requirement into the application. Looking at these numbers, we can deduct that just a single discovery can lessen the actual time needed to implement and cost justify the time spent creating and implementing an architecture.
With architecture comes design standards, guidelines, and consistent approaches to development (referred to as patterns) that allow the application to be more easily understood by new members to the team, better maintained, and also support changes without the threat of rippling the code base.
This benefit also has its criticism against it. The main points of contention are that the design of the application's architecture actually adds time to a project's development cycle, or that ramping up on architecture is too costly for an organization. As we can see from the base ROI statement, this is quite the opposite. However, there is some validity to the time investment to set this in place. Both an organization and a developer who are first approaching leveraging architecture should realize that during the first implementation, they won't see the same magnitude of time savings as noted earlier. The reason for this is that a learning curve absorbs a majority of the time saved, as noted above. You will start to see the benefits pay off in subsequent implementations.
The second reason behind using architecture comes out of the ability to create a set of documents that describe the application. This is where architecture starts to intersect with methodology or the process in which the application is built in. Different methodologies call for different diagrams, requirement formats, and other bits of information to ensure not only sound information architecture but also a clean transition between a user's need and the final product. We will pass on the methodology discussion and instead focus on the documentation that surrounds architecture. It is here that the main point of contention is raised: Many developers and managers feel that the level of detail necessary to properly document an application is much too time consuming. This misconception is due to a lack of understanding of how to effectively leverage the documentation notation.
In the software industry, there has emerged a standard notation for describing the functionality and data associated with the application. This notation is called Unified Modeling Language (UML) and is managed by the Object Management Group, which is a committee of companies that govern this and other languages. The web site for this standard is http://www.uml.org.
Circling back to the point that brought us to UML, it should be noted that although there is a variety to the notation used to document your architecture, it is not a requirement that all of it be used in every design. Relating this to programming, this is like saying you aren't required to use all the functionality of the language on each application. The only requirement is that you document the design enough to guarantee a clear description of the application's functionality—nothing more, nothing less.
For an organization, the benefits to why are clear. They include a faster development time and a living documented design repository of your application. To a developer, though, what is the attraction to become an information architect? One of the most appealing facets is that architecture is abstracted from languages. (This is also another benefit to an organization.) Instead of having to look at what is apparent in the constructs of a development language, architecture allows you the freedom of solving the problem using the abstract basic building blocks and principles found in a design notation. Thus, as languages change, the way you approach a problem doesn't. We'll expand this point a bit in the next section.
Some Architectural Progression
Information systems, like any other industry in history, have evolved from the days of invention and hand craftsmanship into the realms of automation and dynamic structure. At the same time, this evolutionary process has been reciprocal with each major development trend. We have gone from mainframes with text-based interfaces to client-server with rich graphical interfaces and back again with the advent of the Internet and the web with text-based browser interfaces. We now see this coming full circle, first with the introduction of dynamic HTML and now with the graphical benefits of Flash.
Looking to the future, we are heading down this path again with wireless and device-driven systems.
It seems that with each new paradigm, we want to throw out ideas from the past, burn our notebooks, so to speak, and feel that we need to unlearn and relearn to embrace a new technology. It is actually quite the contrary, and the concepts and strategies that we discuss here have been in existence for a long while. If we keep as open a mind to what we already know as we are with what is to come, we'll realize that learning a new technology is merely a question of a new application of our existing architectural knowledge.
What Is Information Architecture?
In its most basic form, information architecture is essentially the collective decisions that are made concerning the design and construction of the various artifacts (components, business entities, packages, subsystems, and so on), such as how they will collaborate and interface with each other to develop an information system.
In the construction industry, a building cannot be constructed without having a blueprint. A blueprint ensures the success and safety of the construction project. Laws exist both in nature and in society that govern the construction of buildings. Architecture is applied to different levels of projects that call for various levels of detail and completeness. The blueprint for a doghouse would be in stark contrast to a blueprint of a 20,000-seat arena.
In the realm of information systems, architecture is just as important to the process of system construction as it is with building construction. You wouldn't let someone build your house without a plan and a blueprint that ensures your home will be the configuration you desire, provide the services you need for survival, and be safe for your family to live in. In the same respect, as a business, we shouldn't let anyone build an information system without a plan and a blueprint that ensures that the system will be configured correctly, provide the services that our business requires, be scalable to meet the business demands, and be safe for our business to operate.
Following this thought through to completion, failure of design can be determined by looking at the two extremes: uncontrolled and nonexistent. Because all systems have an architecture, not starting out with a planned one results in an ad-hoc pieced together system that lacks a consistent flow. Any changes that are needed to this sort of system are difficult to make because the capability to pinpoint exactly where the change needs to made is impossible. On the other extreme is an over-scoped architecture. In this extreme, the needs of the business requirement are not met because the architecture is the focus. In this sort of system, the blueprint is crafted to support unrealistic demand and functionality for the application. Consequently, the timeline to build this is much longer.
New Riders published a book titled Information Architecture, (©2003, ISBN 0735712506) that can provide further information on this subject.