PrintPreviously in the Architecture Practice: Chief Architect Herbert Birchbranch (called Herb in the text) felt quite satisfied when the architecture service portfolio and next year’s budget was set. The service Concern Analysis became a hit, and the communication of the working model had worked out fine. Almost all different entities he had met were very positive.

From unstructured advices to service fulfilment

Before Herb entered the role as Chief Architect, the architecture practice was mainly active through architecture meetings and participation forums. No structured deliveries were done by the architects. The service portfolio, the communication of it and a more offensive way of taking position in different cases had turned things really upside down. The architecture practice had suddenly become a service organisation with expectations. And it has seen an explosion in workload!

A new problem comes to the surface

As per definition with the earlier way of working in mind, there were no useful tools in place to support the architecture practice. It was not only about managing the service delivery activities; the new way of working also drove production of documents. Another perspective that required tools support was the fact that the team was distributed. Support for collaboration was needed.

Herb checked around to see what possibilities were available. The answer was Jabber, Lync, SharePoint, G: and a project management tool. SharePoint could be used for the documents, but none of the actual tools were supporting the urgent needs of activity management. Herb started to get a headache. It was impossible to get an overview and control without spending a huge amount of time.

First attempt to solution

Suddenly one morning while drinking a cup of coffee, Herb remembered how the system development unit manager, Harry Olson, proudly talked about his digital Kanban board a month ago. Could that be something?  Herb called Harry and asked if he could set up a Kanban board for the architecture team. “I will fix that,” Harry said, “but it will take a few days.” A week later Herb was adding the actual actions into the architecture practice Kanban board. At the next architects meeting Herb introduced the Kanban board and assigned his project office architect Roberto to manage the board further on. The complementing directive was that everything we do has to be put on the board, and that it shall be followed-up weekly in an architecture office meeting taking place after the project office meeting.

Finally Herb got in control of the teams’ work again and it became possible to prioritise.

The board, though, brought a new concern to the surface. The architecture team had too many on-going actions, which in turn lead to a very poor throughput. Too few actions got finalised.

Herb decided that the way of working with actions had to be changed.


Figure: The Architecture practice Kanban board after the re-structuring.

After a discussion meeting with the team a new way of using the board was decided. It was based on a couple of rules to support the way of working:

  • Minimize the number of on-going activities
  • Structure the backlog content into different domains
  • All activities shall have a demanded end date
  • All activities shall have one responsible
  • Actual status is written into the Kanban card as a note
  • If related to a project office order, set the reference number in the action header
  • Attach documents related to the delivery onto the Kanban card

There was also a possibility to use colour coding for the actions, or in other terms, to categorise them. Herb decided to use the following categories to start with:


Architecture Start Assurance is related to the same architecture service
Concern is related to the architecture service Concern Analysis
Assessment could be any assessment ordered via the project office
Task is usually an internal architecture office task
Project is architecture capacity dedicated to a project
Participation is participation in any forum as an architect
Delivery object, may sound strange, but it relates to deliveries that are not architecture or output from an architecture service.

There are also attributes available for an activity. Some are graphically depicted in the overview. The following are used from start.


Attributes on an activity

  • Title / Headline
  • Initials of the Responsible (“CB” in this case).
  • Date (if demanded ready date is set)
  • Attachment (if there is one or more files attached )
  • Exclamation mark – Critical priority
  • Triangle in circle – High priority

Herb was aware that this is the starting set-up. Evaluations have to be done continuously to trim the use of the Kanban board.


When an architecture practice starts to work with its “customers” with increased seriousness around a structured service portfolio, the likely result is a lot of tasks, tougher pressure, and higher demand. This is good. It is very good. Because it is proof that the architecture practice has got acceptance as a valuable resource, and that the right playng field has been set. With business demand looming, the problem of lack of resources isn’t pleasant.

The architecture practice always will suffer from lack of capacity. To introduce more lean oriented ways of working is one way of taking care of the issue. Use a Kanban board. It suits architecture work well and keeps the administration to a moderate level. Just keep the number of on-going assigned actions to a minimum. The rest can be parked in the backlog.

A tool is just a tool. The way we work is still the most important aspect. Use of tools, though, may act as a catalyst to develop our thinking and working practices.

Blog to be continued…

Per Bjorkegren AUTHOR:
Per Björkegren is an Enterprise Architect and IT strategist in Sweden. He has worked within Capgemini Group since 1991 and is the practice leader for Enterprise Architecture and IT Governance within Sogeti Sweden, developing the service offerings and speaking at open seminars. He is also the founder and president of SWEAN (Swedish Enterprise Architecture Network), which currently has close to 1000 members.

Posted in: Agile, Collaboration, communication, Developers, Enterprise Architecture, IT strategy, Opinion, User Experience      
Comments: 0
Tags: , , , , , , , , , ,


portfolioPreviously in the Architecture Office: Chief architect Herbert Birchbranch (Herb) managed to build the same basic architecture model around both projects and system maintenance objects. He also realised that building an architecture practice is a continuous process which improves following every meeting with a stakeholder.

Jimmy Had 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 was happy to give Jimmy a 30 minuntes 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 completely the wrong way. He had tried to raise this with the Project Manager and project team several times, but had been ignored every time. During the meeting, the architecture team agreed with Jimmy that the way the integrations were being handled was very wrong, according to the policies around integration.

ArchitectPortfolioThat same evening, Herb decided to create a new procedure, an architecture practice service called Concern Analysis. The thinking being that 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 on a quick analysis and proposal of further actions.

It was decided that the IT management team would receive the result, called a Concern Report. After an initial test from the management team, Herb performed his own Concern Analysis, using Jimmy’s concerns around systems integration as a pilot case.

The result? Important actions were taken to solve Jimmy’s case and the design of integration architecture got prioritised. Suddenly, the architecture practice got another three requests for Concern Analysis.

The birth of an Architecture Service Portfolio

Herbert Birchbranch realised at the end of February that he should bring together the different procedures to create an Architecture Practice Service Portfolio. The most important reasons for doing this were to clarify for the team what they are working with, and to be able to communicate in a simple way what the architecture practice are doing and what they can support the rest of the organisation with. Herb spent some time thinking, before creating 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 summarised as follows:


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. They 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 from the management team – the sponsor of the architecture practice. “Herb can you help me to create a rough architecture budget for 2015?” she asked. 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 service portfolio project. How could he possibly make a serious budget otherwise? Instead of thinking of resources in terms of numbers, he tried to quantify each defined architecture service. For the first time the architecture budget could be made based on expected needs!


For any organisation that has professional intentions, a service portfolio should be a must have. An architecture practice is no exception. A successful architecture practice service portfolio:

– Clarifies for the team what the main purpose is
– Tells the people outside the team 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 new needs show up that the architecture practice should obviously handle, then create a new service.

Finally, the service portfolio 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.

Per Bjorkegren AUTHOR:
Per Björkegren is an Enterprise Architect and IT strategist in Sweden. He has worked within Capgemini Group since 1991 and is the practice leader for Enterprise Architecture and IT Governance within Sogeti Sweden, developing the service offerings and speaking at open seminars. He is also the founder and president of SWEAN (Swedish Enterprise Architecture Network), which currently has close to 1000 members.

Posted in: architecture, Budgets, Enterprise Architecture, integration tests, project management, Requirements      
Comments: 0
Tags: , , , , , , , , , , , , , ,


ArchitectureOfficePreviously in the Architecture Office.

Chief architect Herbert Birchbranch (called Herb in the text) realized that quality measures weren’t that easy to use as drivers for architecture. He then tried another approach, mainly based on the Michael Hammer principles “Put processes first” and “Extend your context”. After this the architecture practice became reality for many people in the organisation. He also had a very positive meeting with two representatives from the project office, Ronald and Laura.

Continuous improvement

The result from the meeting with Ronald and Laura was an improvement of the architecture and project interaction model. In reality the strategic dialogue was a little bit out of scope for the current project office, but there still was a business need for architecture dialogue out there. The project office also already had discussed an early assurance procedure for the projects. These two inputs made Herb Birchbranch to improve his working model. Business Dialogue and Start Assurance was added.

Harmonization1– Start Assurance is a procedure executed on order from the Project Office. It is a quick walk through of the IT strategic principles and high-level architecture principles from the specific projects perspective. It can be seen as an architecture attachment to the project or pre-study directive. The result is a combination of advice and directives dedicated for the project.

– The Business Dialogue became a service that the business can order from the Architecture Office. The reasons can be many; impact analysis, feasibility studies, prospect analysis, participation in meetings with suppliers, and more.

Harmonization is key for keeping it simple

A day in January Herb was invited to a meeting by David, a consultant working with the implementation of a new system management model. During the meeting two main questions was discussed; what is architecture and how could it be integrated in the system management model?

Herb was really glad that he got invited. He strongly believes that good integration of architecture procedures in system management model could create higher long-term value and strength in the architecture. He brought an important objective in to the discussion, to keep it simple and don’t innovate new things if it was not necessary. The result, after a two hour deep dive into system management model and architecture model, was:

– Implement a system management version of the Project Architecture Framework (PAF), the Object Architecture Framework (OAF). A difference between the PAF and OAF was that the OAF shall be created and maintained by the system management team, with support from the Architecture practice. An efficient way to get the architecture roots more out in the operations, where it is actually supposed to be applied.

– Implement the procedure for Start Assurance for system management objects or object groups depending on the areas characteristics, Object Assurance.

Harmonization2Figure: The model for architecture integration in application model 

Still Herb has to wait with the implementation until the yearly planning process starts in three months. But he was very satisfied with his small victory.

Herb’s recommendations

– Build your architecture and architecture procedures step by step in continuous dialogue with the stakeholders.

– If you have to choose, start with architecture procedures integrated in system management model. That will lead to a stronger and more durable realization of the architecture.

– Try to apply the same basic working model for integration of architecture and architecture procedures in the different change processes.

– Produce architecture distributed under central support and control, especially if the architects are seen as “something else which doesn’t concern me”.

– Start to create a basic working model to secure harmonization.


Figure: Herbs basic architecture working model

About the Architecture Office

Per Bjorkegren AUTHOR:
Per Björkegren is an Enterprise Architect and IT strategist in Sweden. He has worked within Capgemini Group since 1991 and is the practice leader for Enterprise Architecture and IT Governance within Sogeti Sweden, developing the service offerings and speaking at open seminars. He is also the founder and president of SWEAN (Swedish Enterprise Architecture Network), which currently has close to 1000 members.

Posted in: architecture, Quality Assurance, SogetiLabs      
Comments: 0
Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,


Per1A few years ago when my daughter was a little younger, we looked together at a couple of cartoon movies about the detective Agaton Sax. What struck me first was the computer he used, named ‘Thinking August’. He fed the computer with speech, pictures and written texts, both machine and hand written.

After some thinking, August replied with some kind of answer – for example photos of the most probable guilty criminals of the actual case.

Mr Sax himself explained his computer in the following way: “Thinking August is a computing machine with no own intelligence. You have to tell the machine a lot of things that we know. I do this by pressing these buttons. It’s called feeding the machine with the data, it is the so called data feed. Without this data feed. Thinking August will not be able to think or be used in any other way. With the right input data, however, Thinking August will provide the most detailed answers to virtually impossible questions.” Pure Business Intelligence, isn’t it? In a way, it’s also Big Data as the computer can make unlimited use of all these different data sources for its analysis.

OK, what is so special with a computer like this? Well, the first thing that hits me is that this idea of a computer was created in the early 60’s. Who was this visionary writer of children’s books in a time when the term “computer” was unknown to a very large majority?

Per2His name was Nils-Olof Franzén, a Swedish literary scholar, author, radio host and director at the Swedish public radio, born in 1916. Obviously he was not the typical scientist that we would expect having these thoughts.

I got curious and had to read more about this guy. Sadly it was hard to find information about him and I found only one photo of him. Maybe he protected himself from the ‘Big Brother’ issue he wrote about in 1970 in the Agaton Sax and the London Computer Plot, which was a foresight into how huge computers and networks could be used in a Big Brother like way such as the NSA stories have become reality today, and as tools for crime like the Internet crime scene today. This was 45 years ago!

From where did he get the influences to create and write about future visionary ideals that were so far away from common understanding at the time?

Inspired by the story I continue to wonder about who are the foreseeing Nils-Olofs of today? What visions are they talking about?

To me it is really hard to think that much out of the box to find something similar. Maybe we should look in the children’s literature as per the original Nils-Olof.

What do you think? Have you discovered any potential Nils-Olof today?

Per Bjorkegren AUTHOR:
Per Björkegren is an Enterprise Architect and IT strategist in Sweden. He has worked within Capgemini Group since 1991 and is the practice leader for Enterprise Architecture and IT Governance within Sogeti Sweden, developing the service offerings and speaking at open seminars. He is also the founder and president of SWEAN (Swedish Enterprise Architecture Network), which currently has close to 1000 members.

Posted in: Big data, Business Intelligence, Digital, Technology Outlook, Testing and innovation      
Comments: 0
Tags: , , , , , ,