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.

Architecture Layers
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.

Enterprise Architecture
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.

System Architecture
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.

Solution Architecture
The common reference for an architect in the present day industry is Solution Architect or Application Architect. Sometimes this role can be referred to as Software Architect. This role delivers the software solution for a given business problem using enterprise standards. This is the first step for any developer of varying experience to enter into the architectural world. Sometimes the resource, who acts as the Solution Architect, can focus on software specific solutions such as Java or .Net. Application Architecture is mostly used in package implementation environments, where knowledge of packages such as any SAP or eBS is required besides having experience in any specific software.

How to Organize the Roles
Irrespective of the type of an architect, the most important factor is to develop the specific role description and expected outcome for each type for a given size of an IT organization. Some suggestions are:

1. The Enterprise Architecture Group can take up the responsibility for business architecture and systems architecture. The Enterprise Architecture Group will set guidelines for System Architecture if an organization is quite large and requires a dedicated system architecture position. Usually this group falls under the CTO (Chief Technology Officer) organization.
2. The Solution architecture can be the responsibility of the Delivery Groups. This role can be played by Tech Leads or Senior Developers when the Solution Architecture role is not formally created.
3. The Enterprise Architecture Group needs to establish a process for an oversight and loop back mechanism from Solution/Application Architecture. This process is monitored through the Architecture Review Board at the beginning of a project and/or after elaboration, for example, before the coding begins.
   • Also, Enterprise Architecture needs to understand the lessons learned from every implementation so that real time experiences will translate in to constant refinement of standards.
4. For smaller IT organizations, sometimes the Enterprise Architect and Solution Architect can be referred to as the System Architect and this resource acts as the bridge between developers and infrastructure. In these situations, developers can become System Architects as they tend to participate in hardware design also.

Figure 2 will demonstrate an example to define specific objectives for a given role. The downward arrow indicates the direction of any project/program and associated transition from one architecture type to the other. In this figure, some objectives are repeated between the types and the reason is the level of involvement for that architect at each development stage. For example, the involvement of Enterprise Architect in Hardware Architecture is to make sure that the standards are followed and the System Architect would involve in the detail design of hardware and would eventually recommend the procurement of hardware.

Figure 2

Architecture Sub Layers
So far, we defined the main layers of architecture. But there are other types, which are equally important and are depicted in Figure 3. All of these types or sub layers play a role in each of the layers with a varied focus. Complexity, size and type of a project will highlight the need of one type of these architecture types over the others. For example, in a highly integrated project with a lot different applications required to integrate to produce the desired end result, Integration Architecture tends to play a bigger role throughout the life cycle of the project.

Architecture role Participation in Project Lifecycle
Figure 4 depicts the typical involvement of each type of role during the lifecycle of a project. Again, the type, complexity, size and duration of a project may change the involvement of these resources and project specific requirements are taken in to consideration to organize or plan for the optimum involvement of architects.

Enterprise Architecture (EA) focuses more at the strategy level such as replacing a legacy supply chain or development of a new financial product. EA's involvement can be more if an organization needs to acquire new tools in terms of software, business packages or establishment of new or modifying the existing infrastructure. EA also plays a pivotal role in making sure that the security/compliance regulations are met by the organization. This group also runs the architecture review boards to ensure that every project is in compliance with the standards and at the same time to provide guidance to the project team, particularly to Solution Architects. The involvement of the EA group diminishes quickly as the project moves to different stages of the lifecycle.

System Architects, as defined above, consistently involve at a certain percentage, and their involvement will be defined by the type of project. For a project, which requires establishing new security architecture or hardware or other architecture type, the involvement can be as high as 60% throughout the project and can be 100% at strategy level. The participation of this resource is required throughout the project, since there can be a possibility to react quickly to accommodate changes. For example, a change in requirements may require making recommendation to modify hardware quickly in order to meet the project time lines.

The Solution Architect or Application Architect will very quickly be involved as soon as the project comes to the initiation stage. The involvement will be close to 100% until the elaboration phase and then tapers down once the project goes in to construction (or coding stage). Some organizations use a Solution Architect as the mentor to developers and seek to provide help for difficult coding tasks such as, when a new technology is adopted.

All of these three types of architects are expected to have working knowledge of architecture sub layers but more is expected from System Architects than Enterprise Architects and Solution Architects.

Interaction between Development and Architecture

Evolving into the Architecture Role
Any developer moving into an architecture role has to become a Solution or Application Architect first. This is the first step in designing the solution and with enough experience can move in to other architectural disciplines. Some developers like coding and may want to stay in that path; but the organizations need to include the mindset that only a proper design and plan will result in a successful project delivery irrespective of having a very strong development team (coders).

A developer can pick a specialty in architecture sub layers if one doesn't want to specialize in one of the architectural layers. Developers that come from database background can become Data Architects and play a role where data design is most required and those that come from language development tend to become Solution Architects. Application Architects tend to come from developers involved in a package implementation such as Peoplesoft or Siebel, but to become an architect in the package space, one needs to be well rounded in an industry such as ERP.

IT organizations need to design sustainable organizational structure to transfer the resources from the development stage to architecture stage. To be effective, a process should be established for a continuous interaction between development groups and architecture groups. This is a very important step for the overall success of the IT objectives and to reach the set goals. Also, the number of positions in the architecture will be much less as compared to development; therefore a suitable process should be in place so that the resources with correct skills and talent can move into these positions.

This article has primarily focused on technology aspects of career path from development to architecture. But there are other skills such as 'effective communication', 'ability to lead' and 'work under pressure', which are also very important and suitable training for the process should be established for an effective transformation.

Conclusion
The objectives presented for Architecture Layers in this article is to demonstrate an idea how to organize the groups. Many IT groups can have their own definitions and names for each architecture type but it is imperative to provide clear objectives, goals and the associated connectivity between the roles.

The foremost and important task in establishing architecture practice is to understand the current strength of IT resources. By using the Layer concept explained in this article and defining the proper objectives of architects associated with either of the Architecture Layers or Sub Layers, any organization can reap the benefits and become an agile organization to participate and deliver the IT solutions for business and become a true partner for business growth.