There are as many architect lifecycles as there are organizations which use an architect’s services. There are also many lifecycle frameworks such as TOGAF, SAFe, FEAF, MODAF, and many others.
1. Understanding Architecture Lifecycles
There are a number of areas to understanding architect lifecycles. Within the engagement model, the lifecycle or architecture method or process, describes the tasks of the architecture team. It includes when and where architects interact in the organization, their common tasks by role, any phases of the architecture approach and inputs and outputs to those tasks.
Architecture Interaction Points
Most architecture lifecycles define the interaction points of the architecture team in alignment with their target outputs and work items. For example, an enterprise architecture engagement model will likely align their target interaction points at a very high level in the organization, such as the executive team or their direct reports. Whereas an architecture team hoping to improve the quality and value of the software delivery lifecycle will likely align more with software delivery teams and stakeholders both inside and outside of IT. A business architecture team will likely attempt to interact with other business units such as sales and marketing and may even report to those lines of business. The following diagram represents the canonical Iasa architecture interaction points by specialization. It should be read, “The business architect interaction points should align with lines of business and/or business capabilities.” A fully compliant architecture engagement model would define these levels and stakeholders or would provide practical guidance for the architect to identify them.
For example, an engagement model might have the following statement(s) defined in its lifecycle.
“The business architects will primarily interact with Sr Directors from identified lines of business and business capabilities. They will work with the Business Relationship Manager (BRM) to lead the business planning and innovation cycle. The tasks included in this will be…” This statement would allow a business architect to identify the Sr Director and BRM related to the capability or line of business they are interested in and meet with them to accomplish their tasks.
All organizations of size go through annual or semi-annual phases. Generally these are a form of a planning/budgeting phase, a do/deliver phase and a review phase leading back into the planning/budgeting phase. The architecture lifecycle method should describe how the architecture team activities fit into these phases for the organization by role and describing inputs and outputs to the activities. These outputs should be linked to Architecture Artifacts described in that portion of the engagement model.
Architecture Tasks and Activities
Of course, the primary element of a lifecycle is to define the primary tasks of the architecture team. These tasks are often defined in the Role Descriptions of the different architecture roles, however the Iasa describes a further level of clarity for the architecture team. An team may choose whether or not to document the engagement model to this degree or not and still be compliant with the Iasa BoK. A written architecture lifecycle task should include a description, any inputs to the task, outputs from the task and process indicators for it’s completion.
An example task within a documented engagment model: Road mapping
To collaborate with the <Business Relationship Manager> to develop the business roadmap and to own and update technology roadmap. Document all technology mappings and dependencies and align to existing architectural models.
- Industry domain and <ORGANIZATION> Knowledge from IT and business perspective
- Output from ‘Identify Scope’ stage
- Existing roadmaps including technology roadmap
- Capability models, Business models,
- Principles, Risks, Constraints, Governance
- Current-state – application portfolio view
- Technology opportunities
- Change request
- Reference architectures
*Advice is an ARB (architecture review board) Advisory this is a non-binding piece of advice typically recorded in a document
|Scope understood||The surface area being considered is understood. At early exploratory stages the scope is highly variable. This indicator captures the sense the extent and boundaries are understood e.g. where are the edges?|
|Business valueàstrategy alignment understood||Traceability from architectural standpoint starts with drivers and influencers. The indicator captures the level of clarity regarding how a strategy will deliver business value.|
|Go/No- go||This indicator captures the from an investment perspective how happy we are to invest money e.g. if I was a shareholder investing would I be happy to invest my money in this (capture not just financials but also opportunity from an innovation perspective).|
2. Industry Lifecycles
A great reference on industry architecture frameworks was created by the ISO and can be found at: http://www.iso-architecture.org/ieee-1471/afs/frameworks-table.html. It includes references to over 60 architecture frameworks though only a subset include an architect lifecycle as defined by Iasa. Unfortunately, there is little understanding or compatibility in the notion of an architecture framework. Most architecture frameworks do not include any notion of a lifecycle method or you must look for external implementations to find such a method. The most famous of these is the Zachman Framework which contains a set of views but not a lifecycle method.
Creating and Publishing an Iasa Compliant Lifecycle Method
Coming in version 3.0 of this guide Iasa will be publishing a compliance method for frameworks, methodologies and training.
Industry Architecture Lifecycles
TOGAF: TOGAF from the Open Group is the most well understood and adopted architecture lifecycle in the industry. It defines the Architecture Development Method (ADM) which defines tasks, phases, inputs and outputs for activities of the architect. While the ADM is an excellent method for creating your architecture engagement model, it takes a broad enterprise IT view of the activities and requires significant commitment at an organizational level to customize and implement. In addition, the scope of TOGAF is very large in as much as it attempts to model the enterprise goals and objectives.
3. Setting Up An Organization Architect Lifecycle
The processes and lifecycles employed by a group of architects should be agreed upon during engagement model development. Iasa’s process component suggests that ALL architects related to an organization be involved and have buy in to the chosen lifecycle. This should include architects who report to other groups or even consultants working with the organization. Also, Iasa suggests that the architecture lifecycle be written separately from other lifecycles such as IT project delivery, governance, risk and budgeting.
The steps to developing a lifecycle include:
- Create an architect-only engagement model steering group
- Create architecture goals and principles
- Evaluate the current PMO or project delivery process
- Create straw man project prioritization, resource and financial allocation practice
- Finalize the architect lifecycle
- Authorize and empower with full Enterprise Architecture Steering Committee
- Ensure consistent integration with Governance and Risk Management
- Regularly review success metrics.
1. Engagement Model Steering Group
- The engagement model should be managed by a cross-section of ALL architects
- If there is no common reporting structure then manage by vote
- This should include customer or service facing architects as well
- The group defines how the entire architect organization
- Engages with the business
- Measures itself for success
- Grows it’s value and capability across the enterprise
2. Set Architecture Goals and Principles
- Set the teams objectives and principles.
- Create measurable goals for architect team contribution.
- Finalize goals and include in individual performance goals.
3. Understand Portfolio Realization
- Learning about the PMO is essential to success
- Find answers to the following questions:
- Where do projects originate?
- How are they prioritized?
- How are they funded?
- How are they assigned to staff members?
- How are teams structured?
- How is progress reported and tracked?
- How are issues raised and addressed?
- How is delivery managed from build to run?
- How are successes rewarded?
- How are subsequent upgrades handled?
- Summarize with the architect team including a pros and cons analysis and consensus
4. Create a Solution Lifecycle
- How projects/products are prioritized
- Engagement level of architect on project
- Required viewpoints, phases, review process, governance and value management procedures
- How architects are assigned to projects
- When architects engage with projects and stakeholders
- AS SOON AS POSSIBLE!
- What pre-existing components will be used and their owners
- Architecture assessment
- Document the cycle including engagement decisions and why they were made
5. Finalize the Lifecycle
- Review the target solution lifecycle with the entire architect team
- Especially ones that don’t report to you
- Make appropriate changes based on feedback
- Evangelize the lifecycle with appropriate stakeholders
- Describe changes to existing way of work
6. Empower the Architect Lifecycle
- If a true EA steering committee does not exist
- Begin the process of creating an EA steering committee
- Do not wait to implement lifecycle changes
- Review each element of the lifecycle, feedback and value to the steering committee
- Describe value in terms of
- Appropriate assignment and prioritization aligned with business value
- More successful delivery and autonomy of staff
- Quicker resolution of issues
- Include how you will measure your success and report to the committee
7. Governance and Risk
- Integration with governance and risk is a critical point of your lifecycle
- “While IT management is about good shepherding of assets and resources, IT governance adds a vision and leadership dimension. “ – Wikipedia
- If governance is the vision and leadership element of IT then architects ARE governance for a solution delivery
- An architect led project will have significantly and measurably FEWER exceptions
- Risk assessment will be done on ALL significant technology decisions