Architectural Layers and Tips on how to Achieve Architecture Consistency, Page 3
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.
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.