In the Agile world, countless self-managing teams are working on a daily basis to deliver a lot of value to their customers with small steps. These are both internal and external customers. On February 5^th we talked about the role of the enterprise Architect in innovations with the participants of  the Knowledge group (CEG) Innovation & IT. In this blog you’ll find an overview of one-liners that may serve as a confirmation or provide help in embedding architecture principles within your organization! 

During a short stand-up-round experiences were exchanged about what works in DEVOPS teams in the framework of architecture principles with a group of Enterprise Architects from leading members from the constituency of the CIO Platform Nederland. In all cases, software is managed and developed in operational teams, in which the team members are responsible for how they deliver the desired use cases. The idea behind this is to empower people by making them themselves responsible for their result. 

However, a frequently heard problem is how embed things like security, privacy and architecture in the teams in this 'unstructured' environment. "You have to organize and facilitate this, it doesn’t organize itself"; was said by Ruud Overbeek, Enterprise Architect of Thales Nederland. He highlighted during his presentation about the role of the architect at Thales:

• Reduce the complexity to a minimum
• Facilitate good balance between Risk and Value
• Select important technologies to invest in
• Use practical principles and practical guidelines for teams
• Ensure a close relationship between Business & IT

His entire presentation can be found in the online Knowledebase (only available for the members of the CIO Platform Nederland).

We hope the following one-liners will help other architects and of which they should be aware when working with architectural principles:

• Let teams themselves come up with the principles, with which they can do their work in a good way: devise themselves instead of imposing.
• Principles are giving direction, they are not restrictive.
• "Give Freedom", as much as possible. Beware! Is partly also dependent of the technology, it can’t be worked out uniformly in all cases.
• Check the coherence of the principles, bring balance in what's in it for architecture and for development and maintenance.
• Provide a concise set of architecture principles.
• Standardize the IT landscape whenever possible. Note: This is not an set goal on itself. Sometimes a deviation is cheaper in a certain situation.
• Automate as much as possible, so that as much as possible self service can take place and people doesn’t encounter any obstacles in this.
• Don’t act like a police officer if the principles are not followed.
• Develop the principles by including implications and examples, or even a case from daily practice in which the principle is applied.
• Review the principles annually by updating the info around it, not so much to completely revise the principles.
• Create a community about "Architecture" – a guild of 'architect' roles.

One of the responses after the intensive and interactive program of this meeting: "Interesting to brainstorm together on a specific topic!".

Meeting Knowledge group (CEG) Innovation & IT 
Thales, Hengelo, February 5th 2019