The Iasa Core Lifecycle
The Iasa Foundation Lifecycle is a simplified process for smaller architecture teams. It is designed to:
- minimize process steps and overhead,
- focus on project delivery,
- create value from innovation,
- embed the architect in the business value process.
This lifecycle has been taught in the Iasa Core Course for over 6 years and has been successfully deployed in some of the largest and smallest architecture teams in the world.
The Plan Phase
Each year at almost every company in the world, the executive leadership team does a dance. They set goals for the business for the upcoming year, look at where they want to invest heaviest, and go through a budget process to prioritize spend. This dance will start as early as 6 months before the new fiscal year in larger organizations.
As they look at what they will spend on technology, they consider the existing operating budget and how they can reduce costs, especially with regard to IT. For investing in new technology-based capability they balance against other areas to invest, including buying other companies, buying bonds, reducing debt, and everything else that happens inside of their organization.
If you are a consulting architect or focused on delivery inside of an organization you may not be involved in providing input to this portion of the lifecycle, but it happens. As you grow your skills and advance to more senior positions you will be expected to perform in this capacity, and the sooner you start the more connected your organization will be and faster you will advance your career.
Goals of this phase
- Create and communicate a business technology strategy that delivers real business value through:-
validation of the information, eliciting the architectural significant requirements from the exec stakeholders and enhancing with technology strategy.
- Appreciate the different types of business value and how to calculate them.
- Create project schedule, resource profiling, a master schedule and addressing resourcing challenges.
- Understand the value an Architect brings to the planning exercise as distinct to the Project/Program Manager.
- Select and sequence competing projects as a collective team based on key drivers.
Work as a team, presenting and justifying to peer teams and stakeholders your workings.
Review Business Case/Create Business Case
A business case captures the reasoning for initiating a project and what value the project should provide. Architects should verify the value of the technology, add strategy, and make sure the solution fits the governance model, existing portfolio, and can be supported by the Operations group. They can also add value by initiating business cases for projects they feel will add business value. Business valuation, compliance, and decision support skills will help during this phase.
As a consulting architect, you typically do not have visibility into this phase of projects, but you still should know what is expected and what the output of this phase is. By gaining status as trusted advisor and having business skills, you will be sought out to provide input earlier in the lifecycle of a project.
Thereby allowing you to have greater business impact. Some things to consider:
- What is the business need?
- What approaches should be considered?
As you are adding technical strategy don’t let others trivialize the complexity. For instance, in a B2B solution all we have to do is connect two systems. How hard can that be? Try to identify the areas where you expect push-back or adoption issues, especially as related to re-use. Many teams will want to build a brand new system rather than taking a buy or reuse strategy.
Business cases have some key components, including an executive summary which is normally only one or two paragraphs long and provides high level details of the need and how it aligns with the organization’s business objectives. There will not be many details available so project overview, evaluation, and project selection justification will be high level.
In your current role as an architect you may or may not be part of the process of reviewing business cases, but in organizations with moderately mature practices, there are architects the help write and review business cases. As you grow in the role of trusted advisor you will have to be able to provide relevant input into business cases and increase your personal value to the organization. If you are in a consulting role, this reflects well on you and the company you represent.
As you review business cases, make sure the intended value of the project is clear, including how that value is calculated and will be measured and tracked. Remember, you want to capture as much data as you can to help you provide valuable input but do not want to be seen as a roadblock.
Validate The Numbers and Calculate Value
Many junior architects suggest they are given business requirements and provide a solution based on those requirements. They are not responsible for the accuracy of the business case or the business value the solution provides, much less whether the solution will solve the intended problem. This is not the case.
As technical experts shift into the role of an architect they are responsible for understanding and validating the business intent of a business case, explore the numbers and highlight anomalies, and make sure the technical solution provides back the greatest business value to the organization.
As an architect you must learn about the business the organization you work for or are consulting for are in. Standard and Poor’s provides information on basic financial information for a business and who is on the executive staff.
Typically the waiting room of a business has industry magazines relevant to their business line and provides a good resource for starting your research. Additionally, organizations like Cutter, Gartner, and Forrester provide valuable insight into industry trends.
Part of your toolkit needs to be a robust set of resources to quickly research technical and industry trends and how technology is being used in various industries.
You may have the best idea in the world and may feel that the value should be obvious. But if you haven’t determined how valuable you are not likely to be able to secure funding for the project, or worse may have a project in flight that gets reduced in budget and scope and have no idea what impact that will have on the value of your solution.
Once you know what projects have been funded for the year, you must look at the available resources and the project inter-dependencies in order to provide input on when projects should be started and who will be assigned to each and at what point of the project lifecycle.
IT environments with little or no architectural practice portfolio planning can be left to people that do not have a broad understanding of IT or current and future capabilities. Additionally, they may have some opinion of technology that is formed through the advertising in the sources they use to gain insight, and that may lead to portfolio planning based on the latest hyped approaches and products.
There is almost always a tension between project managers and architects. Projects managers are responsible for the project’s budget and schedule while the architect is responsible for the intent of the architecture. The PMO is often responsible for setting up the portfolio scheduling but do not understand the interdependency between projects and may not know which ones provide strategic value.
As an architect you should leverage your visibility of all the projects that are being funded to provide insight into which should be started first.
|Project or Feature Scheduling
|Architect Prioritization Worksheet
The Build Phase
This is often seen as the core of the architect’s job. Design is a fundamental part of architecture and requires collaboration, uses modeling, and enables us to reduce complexity. Design methodologies and processes are NOT about technology alone, but about simplified solutions to a problem that delivers business value.
We are expected to be able to create architecture that is mapped to business requirements, can be implemented and operated, and is traceable back to the business requirements. While creating architecture we should be able to leverage tools that ensure our solution will work and should leave artifacts that are evergreen and discoverable.
Analyze Architectural Significant Requirements
As you are researching requirements the stakeholders will have a strong idea of what they need from a business perspective. You must be able to validate the requirements they provide, but should also ask questions to determine if there are other things that could provide benefit and what their long-term goals are. For instance, at Tinkleman, if they want the ability to sell downloadable ebooks you may ask if they want the ability to sell downloadable videos.
As you are discussing the non-functional requirements for the solution you must describe the level of quality attribute required to satisfy the business need. You must also discuss the tradeoffs between the various quality attributes. For instance, if the stakeholder wants an ebook solution with a completely user-customizable interface you should discuss the additional cost in user support that may occur.
Constraints may be the hardest for the architect to uncover. A good place to start is researching the current governance for limits on current products in use, staffing skills, operational tools in use, and procurement policies. Next make sure you understand the compliance issues that will manifest as constraints to what you deliver.
An Architectural Requirement is one that:
- Impacts revenue/cost to the level defined in the engagement model
- Impacts quality attribute tradeoffs
- Impacts constraints on the output solution
We all have tools in our toolkits that we use more than others. This can lead to starting with a preconceived notion of what the solution. Ideally the architect will create a generic architecture and then create the product-specific architecture.
Every component you add to your model should be able to map directly back to the value and goals defined in the business case or an architecturally significant requirement. We should plan for long-term viability but only build what is necessary at the time. See Architecture Value.
As you make selections you should add justification to your architectural artifacts. For instance, if your solution requires access from generic clients you may decide on a web server. Add justification to describe why you made the choices you did. The reasoning may be aligned with a functional specification, a non-functional requirement.
A generic architecture indicates:
- State locality and flow
- Behavior locality
- Transactional behavior
- Any high-level patterns (such as Model-View-Controller)
- Define the requirements that justify it
For each component
- Define the requirements that justify it
- Ex: An online store must have a Web server
- Indicate its connections with other components
- Write a description of its purpose in the architecture
- Write guidelines for its use
According to Iasa, the architecture is not the model or design, it is the description of decisions and their value.
Product Specific Architecture
Look at capabilities for a fit to existing technology expertise and governance. If you are suggesting a product that is not approved for use you may want to reconsider that product, but if it is the best product from a short or long-term perspective then it may be worth working through the exception process.
As you introduce new products you must set the expectations of the delivery team and help them obtain the skills they will be to be effective. Additionally, operations will need to know how to monitor, manage, and maintain the solution. End users and helpdesk staff must also be considered and you must form an idea of how the solution will land and adopted by the users.
Views, Viewpoints & Perspectives
The definition of view and viewpoint IASA recognizes is the same as IEEE 1471 and ISO 42010.
Some examples of viewpoints include;
- and deployment.
A view is created using the information in the viewpoint and provides the architect a way to represent their architecture in a way that is consumable by different audiences.
As an architect you may not have ever worked in the operations side of a data center. You might not have an idea of what is important to the people that do and may not know how they describe a runtime environment. By leveraging viewpoints you can create an artifact that will provide a view into your architecture that is consumable by the operations team.
For those of you that have a developer background viewpoint is to view as class is to instance. We recommend using the viewpoint library defined by Nick Rozanski and Eoin Woods.
The Run Phase
In some organizations the architect is only involved in project prioritization and creating architecture and others manage delivery of the architecture into operations. With other organizations, the architect is introduced when the architecture is created and follows the project through to delivery to operations.
Ideally, the architect is involved is project identification, prioritization, creation, delivery, and continues to monitor a solution while in operations and has provisioned the solution so business metrics for success are monitored and captured. This module provides insight into the skills the architect uses during this phase of a project.
Knowing and managing stakeholder communications is a critical part of the architect’s job and pays great dividend as the project progresses. As with any skill, experience applying the knowledge you have obtained allows you to successfully drive communications.
- The benefits of using a stakeholder-based approach are:
- Powerful stakeholders can help shape your project from the beginning
- Powerful stakeholders have access to more resources if you need them
- If they are satisfied they will communicate that with others at their level
- Will help you determine others’ reactions and influence them
Key questions that can help you understand your stakeholders are:
- What financial or emotional interest do they have in the outcome of your work? Is it positive or negative?
- What motivates them most of all?
- What information do they want from you?
- How do they want to receive information from you? What is the best way of communicating your message to them?
- What is their current opinion of your work? Is it based on good information?
- Who influences their opinions generally, and who influences their opinion of you? Do some of these influencers therefore become important stakeholders in their own right?
- If they are not likely to be positive, what will win them around to support your project?
- If you don’t think you will be able to win them around, how will you manage their opposition?
- Who else might be influenced by their opinions? Do these people become stakeholders in their own right?
Modify and Update Artifacts
Architectural artifacts are the output of effort expelled on a project. This can include;
- meeting minutes
- whiteboard sessions
- any other deliverable you capture.
Storing and maintaining 600 pages of documentation for every project may be too much content and might make discovering relevant information impossible.
As you create a knowledge management solution consider what artifacts are vital to maintain and how you can identify metadata that makes the important information discoverable. For the artifacts that are stored and maintained set a schedule for review or retirement of the content.
You are paid to deliver technology strategy that results in business value to the organization.
While some projects should;
- be killed,
- most should be completed,
- and operated.
The architect is responsible for making sure that everything that is build is necessary and the goals that were set to describe success are met.
The project team is concerned with on time and on budget delivery.
The architect is concerned with business value being delivered and a mechanism being put in place to capture and provide evidence of success to the executive sponsors over time.
The Manage Phase