As an IT Architect, it’s important to stay up to date on the latest trends and best practices in your field. Part of that is being familiar with the various acronyms that get thrown around. To explain the most useful concepts in both traditional and Agile architecture, we came up with a list of 10 acronyms every agile architect should know, along with a brief explanation of each. Read on to find out more about these essential concepts.
1. ADR: Architecture Decision Record
An Agile Decision Record (ADR) is a document that tracks decisions that are made during a project. These records are used when deciding on a significant aspect of the IT architecture to catalogue all aspects of the decision. They include the reasoning behind the decision, who made it, when it was made, the broader context, its consequences, and any other relevant supporting information. Keep these records in mind when you are conferring with the different stakeholders on a project, and be sure to include the Value Analysis (VA, see below).
2. BPI: Business Process Improvement
Business Process Improvement (BPI) is a methodology for streamlining business processes. The goal is to improve efficiency, accuracy and effectiveness, while keeping costs down. As an IT Architect, you are responsible for these improvements, especially as an Agile Architect. Luckily, the Open Agile Architecture (O-AA, see below) will give you the necessary flexibility to keep improving those processes as the project continues.
Keep in mind that BPI is not the same as Business Process Re-engineering (BPR). Whereas BPI streamlines existing processes, BPRE seeks to restructure an organisation and its methods to take advantage of technologies like machine learning and AI by using new entirely new processes.
3. ITSM: Information Technology Service Management
IT Service Management (ITSM) is an umbrella term for a set of practices and processes that are used to manage and deliver IT services. This includes everything from design and implementation to delivery and support at the customer. ITSM looks at both processes and activities. It includes best practices for service delivery, service support, and continuous service improvement. ITSM includes a lot of aspects, but as an Agile Architect, you will need this kind of bird’s eye view.
4. MVP: Minimum Viable Product
A Minimum Viable Product (MVP) is the version of a product with the minimum number of features needed to be viable. For example, an MVP of a mobile application is one that already works, but does not contain all of its final features yet. The MVP is often used as a starting point for further development, as promotion for early customers, and for validating the idea during the product lifecycle.
The Minimum Viable Product also helps the product team to get feedback from users as quickly as possible, so they can iterate and improve on the product. Of course, this approach works perfectly with the philosophy of Open Agile Architecture (O-AA). It’s all about improving along the way and not being afraid to adjust where necessary.
5. O-AA: Open Agile Architecture
Open Agile Architecture (O-AA) is a framework for developing software architectures using the principles of an Agile way of working. Just like Agile development of software itself, O-AA emphasizes iterative development, customer collaboration, and flexibility when developing architectures. This helps to guide organisations through their digital transformation in manageable increments, accounting for changes in scope and requirements along the way.
6. REST: Representational State Transfer
Representational State Transfer (REST) is an architectural style for building web services such as APIs, which are then called RESTful. These RESTful web services are stateless, meaning each request is independent of all others. The aim of REST is to describe a uniform interface, so services between companies can communicate more efficiently.
As an Agile Architect, your proposed architectures will change as the project progresses. Having a uniform interface where the services are designed with the same specification will not only make it easier or them to communicate, but also to be replaced and updated where necessary. When paired with Service-Oriented Architecture (SOA, see below), this will result in powerful yet flexible systems.
7. SOA: Service-Oriented Architecture
Service-Oriented Architecture (SOA) is an architectural style for building software applications as a set of reusable services. If you use SOA, it means that your services are self-contained and only loosely coupled with each other. Typically, the services are centred around a single business capability. This makes them easy to change or replace without affecting the rest of the application. As an Agile Architect, you will be changing applications on the fly, which makes Service-Oriented Architecture a great fit.
8. UX: User Experience
User Experience (UX) refers to how users interact with and use a product or system. It describes the overall experience of using an application or website. UX assessments usually include objective aspects such as a font and spacing, coupled with the subjective interpretation of those aspects.
While it can be challenging to interpret that subjective feedback and adapt the application accordingly, it is essential to the success of your architecture. A good UX is intuitive and easy to use; a bad UX frustrates users and leads to abandonment of the product.
9. VA: Value Analysis
Value Analysis is a technique used to identify the essential functions of a product or system and eliminate non-essential functions. This selection process helps to simplify designs and reduce their cost by looking at the value that they add, both during and after production. Since you will be making many changes as an Agile Architect, it’s good to take this value analysis into account when making decisions. Make sure to include them in your Agile Decision Records, so your stakeholders can discuss using a solid foundation.
10. IS: Information System
Information System (IS) is a term used in business and computer science to refer to the combination of people, processes, data, and technology that together support the operations of a business. An information system can be as simple as a pen and paper, but it typically denotes complex applications such as an enterprise resource planning (ERP) system.
As an Agile Architect, you deal with the complexity of information systems and application landscapes on a daily basis. It’s important to employ the bird’s eye view we mentioned above, and look through the complexity to see the connections. Only then can you upgrade and replace the existing system in a way that will be satisfactory to all your stakeholders.
