English | EN In the Architecture Office: Service-portfoliozation
Jul 11, 2014
Chief architect Herbert Birchbranch (called Herb in the text) has managed to apply the same architecture model on both projects and system maintenance objects. He also has realized that building an architecture practice is a continuous process which gains from every meeting with a stakeholder.
Jimmy got a concern
One day in February a technical project manager, Jimmy, invited himself to an architecture meeting. Herb thinks that every interaction with the outside-architecture-practice-world is important, so he gave him a 30 minutes slot on the agenda.
What Jimmy wanted to discuss was a big concern in one of his projects. He felt that the integrations being planned between two systems were designed in a completely wrong way. He had tried to get attention of this from the project manager and project team several times, but had been ignored every time. The architecture team agreed with him that the ways of handling integrations were very wrong according to the policies around integration.
The same evening Herb decided to create a new procedure, an architecture practice service called Concern Analysis. It should be possible for anyone to confidentially raise a concern and get a Concern Analysis done. The next day the procedure was defined with a procedure description and a template for the Concern Report. “Aaah, a whistle blower function,” Peter the IT strategist said with a smile. It was important that a Concern Analysis should never take more than two weeks. The focus should be a quick analysis and proposal of further actions.
It was decided that the IT management team would be the receiver of the result, called a Concern Report. After a go from the management team, Herb performed a Concern Analysis with the actual case as a pilot case.
The result? Important actions were taken in the actual case. The design of integration architecture got prioritized. Suddenly, the architecture practice got another three requests for Concern Analysis.
The birth of an Architecture Service Portfolio
Herbert Birchbranch realized at the end of February that he should put together the different procedures in an Architecture Practice Service Portfolio. The most important reasons were to clarify for the team what we are working with and to be able to communicate in a simple way what the architecture practice is doing and what they can support the rest of the organisation with. He spent some time thinking and then created a simple structure based on three main types of architecture services:
- Process related architecture services
- Assignment related architecture services
- Representation related architecture services
The service portfolio for architecture services related to process was summarized as follow.
These services are related to processes in place, in this case the project model and system management model.
Assignment related services are the ones that can be ordered from the architecture practice. It can be allocation of an architect to work within a project, quick assessments, design of viewpoint architectures, and concern analysis.
Representation related architecture services are allocations of specific architects to participate in more continuous forums.
Time for budgeting
One day in late February, when Herb was just about to finish the service portfolio definition, he got a call from Christina, the sponsor of the architecture practice in the management team. “Herb can you help me to create an architecture budget for 2015?” she asked, and continued “Just rough…” Herb answered, “Of course, but I will use the service portfolio as a basic foundation, and it will not be just rough”. “Okay,” she replied and the call was ended.
Herb was really glad that he had started the work with the service portfolio. How could he possibly make a serious budget otherwise? Instead of thinking resources in numbers, he tried to quantify each defined architecture service. For the first time the architecture budget had been made based on expected needs.
Conclusion
For any organisation that has professional intentions, a service portfolio should be a must have. An architecture practice is no exception.
The architecture practice service portfolio:
- Clarifies for the team what the main purpose is
- Tells the people outside what we do
- Gives us the necessary foundation for a serious budget
- Defines the integrations to other processes
As shown with Jimmy’s concern above, the service portfolio is a living thing. If needs show up that it is obvious that the architecture practice should handle create a new service.
Finally, it creates a very good discussion on what we should work with and why, which seldom is clear within a quite large and often distributed architecture team.
About the author
