Architectural Layers and Tips on how to Achieve Architecture Consistency
Along with the Project Manager, Architecture is recognized as one of the most important resources in any IT organization. Yet many IT organizations struggle to define the role of architecture and to apply the architecture principles consistently throughout the life cycle of projects from the conception of business strategy to the IT solution delivery. Though there could be several reasons, the important reason is the inability of IT to reorient itself to structure the architecture roles to deliver the results required in a quickly changing IT landscape. The new paradigm shift towards IT alignment with business for growth makes the case for adaptable architecture framework and structure even more compelling.
One of the core objectives of an architect is to influence the development groups to use the set standards. Sometimes even with properly structured architecture groups the final result can be elusive due to disconnection between architecture and the rest of the development. This can be due to the development resources with outdated skills combined with the lack of organizational focus to train these resources to address the new challenges. Some suggestions mentioned later in this article will help IT organizations to overcome this challenge and can make development groups more attuned with architectural direction.
The presence of several definitions of architects in the IT industry and lack of well defined objectives for each architect role makes it difficult to adopt the architecture consistently. Another challenge is the development of proper job descriptions for the architect.
This article will try to explain the definitions of different architecture types that exist today in the industry and will attempt to establish the relationship between each other. The contents presented in this article can also be used to create a road map for developers to become architects or solution architects to become enterprise architects.
Defining true architecture roles is just the beginning and the true value for IT can only be achieved when these principles are applied consistently. To achieve architecture consistency and to eventually attain the desired maturity, where results are measured and improvements are part of the process, every organization should have a framework in place to identify different tasks to be performed under each of the different types of architectures with a minimal overlap of work yet producing the desired results.
Architecture Layer is a concept where different architectural principles are applied at different stages of methodology to deliver projects of varying complexity and size. Rational Unified Process (RUP) terms and descriptions are used to demonstrate the examples.
Depending on the size and type of the project or any strategic initiative, different skills in the form of strategy planning, software and/or hardware architecture are required. The size of an IT organization will usually dictate the complexity of the project or program, which might require experienced architects and a different set of architectural skills to deliver such projects or programs.
There are several types such as Enterprise Architecture, Systems Architecture, Software Architecture and Solutions Architecture and it is necessary to establish the scope and definitions for each of these types. These relationships are explained through architecture layers and sub-layers, which are depicted in figure 1 and figure 2.
From a top-down approach in terms of involvement from strategy to technical solution delivery this type of architecture is most important in setting up proper foundation. Though the role existed for some time, the Enterprise Architect is now taking a very important position and playing a crucial role as part of the new alignment of IT with business objectives and goals. The Enterprise Architect typically works with business to define the road map for IT. Also, Enterprise Architect is responsible for defining technology standards for the rest of organization to follow. The resources that will play this role typically consist of working experience with all the rest of the architecture types.
This role falls between Enterprise Architect and Solution Architect but partially involves in the development of a project. The involvement of this role varies with each type of the project; with a much greater involvement for a complex or a large project to minimal or negligible participation for a smaller project. Also, sometimes this role can be supported by either Enterprise Architect or Solution Architect depending on the background of the resource designing the architecture.
System Architecture also requires more involvement with infrastructure than the software design and development itself. Sometimes a typical infrastructure project, which usually requires more database and hardware type of design, may need only System Architect. The resources that evolve in to this role are usually from hardware, security or database areas. Very large organizations may have a dedicated role for this type of architecture requirement. But the objective of the System Architect is the delivery of the software solution or to prepare base for such delivery in the future.