Best practices
Common language
One of the most important factors for the successful implementation of LAF and consequently achieving a good quality architecture is the development of a common language together with business, programmers and other relevant stakeholders. Appropriately built language allows discussions about architecture between business representatives with each other or with people from the IT department.
This language should be simple and based on a simple definition of what an Application and Capabilities are, and how we can define the future of a given business area.
We recommend using the DDD (Domain driven design) concept as a method to develop an appropriate communication language
Division
Most large organizations have a complex business model based on a multitude of products, services or processes. In such organizations, it is worth making reference architecture prepared for a given business area. The entire reference architecture should preferably be divided according to the organizational structure or across value streams and each part should be developed separately. This creates domain reference architecture.
Architecture Log
Due to the fact that the organization is changing in particular, there is a rotation of employees, it is very important that there is a knowledge base about the decisions taken. This allows us to maintain business continuity and pursue the goal consistently.
Architect Log is a database in which important decisions, such as:
- a decision on choosing the purchase of a new technology / Application / Component
- acceptance of an exception to the Reference Architecture or Standard
- AR publication or standards
- elimination of Applications/ Components from the environment
Continuous improvement sessions
Every 2-4 week should be held a cadence basedpatice continuous improvement session for Architects. The meeting should take anywhere between 1.5 h to 2h. The retrospection session is well known in Agile Ways Of Working and already very well described in publicly available materials and that is why a particular technique should be adopted form that world and it will not be covered in this material. If an organization already uses an agile approach within an organization, we highly recommend to reach and adapt the techniques which are well known in the organization. The important thing is to notice that architects take part in SDLC retrospections independently from Architects continuous improvement sessions and bring any global discoveries into this meeting. An example session result may be: a change in the component evaluation model, a change in the SV template.
Fast Tracks
Not every initiative should be covered by Solution Vision. Initiatives that are within one existing Application and do not change its capabilities should be implemented along a fast path.
Anti Pattern
Target Architecture
The main problem and, consequently the failure to implement LAF is to misunderstand what Reference Architecture is. Reference architecture is interpreted as a big vision of transformational change is often called a program with a schedule, budget estimation and other design elements. It becomes a very distant goal, mostly for many years. It entails all the consequences of designing the Application environment in a simultaneously changing business. In most cases, the transformation program is abandoned at the first big problem in the delivery process. Then all architecture is abandoned. LAF supports the gradual pursuit of reference architecture which is changing with the changing business situation.
Depp design
Architects who are not developers of that Application and do not work directly on implementation should not design the implementation of functionality in a given Application. Teams of programmers are responsible for the technical design. The teams agree on specific functionalities with business. Architects should build the basis for implementing functionality in the form of API guidelines, integration methods, and major technological changes. The most efficient model for implementing architecture is the participation of architects in the life of development teams. This participation depends on the type of project and its stage. At the beginning of the project, we recommend the Architect’s should closely collaborate with the development team. In the later stages, the Architect should support the team as needed.
Architects out of SDLC
If architects are not included in the delivery process and do not work with the business and developers, they are consequently isolated from the knowledge that affects the Application environment and from the state of the environment. In practice, it is not possible then to track and implement the reference architecture. Application teams will shape the environment in a way appropriate to the Application they create without seeing a wider context. A business working with specific Requirements will focus on achieving short-term goals. Architects must be a part of SDLC to be able to implement changes them in long-term perspective
Architecture as a bottleneck
Too extensive documentation of processes and elements and as a consequence a huge amount of work for architects will make architecture a bottleneck. This will lead to bypassing the architectural aspects very soon. All repositories should be built at the level of minimum compliance with requirements and contain only information needed by stakeholders of architecture and SDLC
Tools
LAF is a set of good practices that are independent of the tools or lack of them. LAF can be implemented using only a spreadsheet. However, a very good idea is to automate some steps and store data in repositories with greater analysis capabilities. We recommend building / owning:
- A repository in the form of a central database giving the opportunity to work for many people in this application team at the same time. You can start with a spreadsheet in a shared folder
- Having an architecture portal containing information about standards, architecture log, reference architecture
- Applications that automate the collection of surveys from end-users of Applications
- A tool for automating the collection of information about Applications, e.g. from static code analysis systems or bug trackers
- Tools for automating the collection of metrics