Architecture & DesignArchitectural Layers and Tips on how to Achieve Architecture Consistency

Architectural Layers and Tips on how to Achieve Architecture Consistency

Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

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.

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.





Click here for larger image

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.





Click here for larger image

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.





Click here for larger image


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





Click here for larger image


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.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories