It cannot be understated how much processes also show people how to interact with the architecture group and what the architecture group does. Before you start drawing pictures or designing solutions, you need to think about what processes you are going to use to do architecture. Questions like when does the architecture team interact with the business requirements process and how does an architecture review work can be answered and your teams value be measured through process, much like any other part of the business. Once you have a process you can work at making it more efficient and showing value through metrics and successful interactions with other business and IT processes.
The key in creating a successful process is ensuring that it works within your organization. For example, if you work in a business that has adopted an agile methodology, you will need to make sure that the architecture processes align properly with the way the business has chosen to work. You would not want to go through the entire backlog and create detail drawings for every item because the agile methodologies are focused on solution delivery and not documentation. You will need a process that will focus on solution delivery and not documentation. Creating the right process for your organization’s style is not easy,
A good process will teach and grow people and can really make your architecture team shine. It is not a substitute for competent architects, although it can be used to develop people. It can decrease bureaucracy, improve deliverable quality and improve productivity. A good process needs to be created with a balance of managerial skills and architecture skills to generally get it right.
Regardless of the processes you invent or borrow, a good architectural process will generally need to cover the following areas:
Championing/Initialization
What is the process for introducing new architectures? How do you get buy in for the new architecture or major design decisions? How do you gain management, development and infrastructure buy-in for the architecture? How is the architecture team going to support the developers in implementing the architecture?Requirements
How does the architecture team interact with the requirements gathering process? What level of review and input does the architecture team need over the requirements process?For example, the architecture team needs to have a process for getting the requirements from an architecture point of view. The architecture team will need to be integrated into the process to review the functional and non-functional requirements to make decisions around technology reuse and how the performance and security non-functional requirements will be met before the business requirements document is approved ideally, so it can incorporate changes from the architecture team.
Design
What framework is used for design if any? What artifacts are due and when can they be expected in relation to each other and other processes? A key point is to remember that artifacts should support decision-making, so they will need to be available to support key decision points in business processes.Review/Validation
What is the architecture review process? How do you validate or vet architecture? How do changes get addressed in the architecture?Deployment
Does the deployed architecture match what was designed? How is the deployment of an architecture supported by the architecture team? How do changes get implemented into the architecture?Governance
How are technology standards introduced and approved? How do the standards get publicized? What happens if the standards aren’t or can’t be followed? What does the governance organization look like? What needs to be reviewed by the architecture team or does not need review?You will need to document the processes you create and make them widely known. A process does not require complex tools to document. You can use PowerPoint with bullets to represent simpler or high level processes or you can create swim lane diagrams with Visio to represent a more detailed or complex process.
An Example of Swim Lanes to Diagram a Process
The following are some resources about software development processes and architectural frameworks to get you started with creating an architectural process.
Waterfall/Spiral
These methodologies will require that the architectural process focus on the architecture as a whole early and planning up front including proof of concepts. You will need processes to handle reviews of the architecture during formal change requests. You will need an Architectural Control Board to review and approve complete architecture before the overall process can move to the next step or phase. A waterfall approach will require a solid software architecture up front and controls over changing it through the process.Rational Unified Process (RUP)
The creators of RUP looked at why software projects failed and created a process that addresses these issues. It is a software process that focuses on documentation to aid communication in a software development process and created the commonly use modeling language called the Universal Modeling Language (UML).Click here for more information on RUP.
Agile Software Development and Agile Architecture
Agile architecture processes would focus on managing change, complexity, solution delivery over documentation (documentation is still important, just not the focus like in RUP) and enabling the delivery of the next cycle.
Frameworks
Frameworks represent different views that various stakeholders of the system will find informative and useful. These frameworks generally represent the design phase of your processes and can help you decide and discover the information that you may need to create the appropriate architecture. Generally, they make it easier to think through the scope of the architecture process and should be incorporated where appropriate. There are many frameworks, but the following are the most common.Zachmann EAD
The Zachmann Enterprise Architecture Framework defines layers from the most conceptual called scope, down to the finest detail of the physical implementation.Across each of the layers you need to pay attention to data, function, network, people, time, and motivation. This framework was the first and established much of the terminology we use in architecture today. I think of the Zachmann framework as more of a tool to think through architecture, than a process to do architecture. See a detailed picture of the Zachman Framework.
TOGAF Enterprise Architecture Description
This is the Open Group’s popular framework for application and infrastructure architecture that is designed to work within your processes.
Enterprise Architecture Body of Knowledge (EABOK)
The EABOK framework focuses more on the process of architecture and showing the value of Enterprise Architecture. This is an interesting read as it compares various frameworks like Zachmann and TOGAF, but it is on the complex side.
Gartner states that 40% of all architecture programs will fail by the year 2010 because they don’t show value. This is because many new architects tackle the design and documentation aspects of architecture first, before establishing it as a part of the business processes. While documentation is an important part of architecture and communication, it will not make your architectural program a success. You need to focus on the processes which will define your interactions with the rest of the business, establish roles and responsibilities, gain management buy in, facilitate communication and establish architecture as an intricate part of the processes.
Mitch Ruebush is the Leader of the Architecture Team for ING DIRECT, the largest direct bank in the U.S. He is president of the Philadelphia chapter of the International Association of Software Architects, and serves on the IASA Board of Directors. He has authored many books and articles and speaks at a number of events each year.
Comments