Is Architecture still Relevant when we are Agile; Moving Everything to Cloud; Going AI?

You still need to:

• know where you are and what you have and what state it is in

• know what you want (at least at a conceptual / business level)

• know what you need to move from current to future

• guide choices, implementation and make tradeoffs between paths of action

• have relevant data, information and content to deliver the products and services and make decisions

• evolve your application and technology landscapes to take advantage of developments while managing risk, security, privacy and efficiency concerns

• partition work across teams in a way that allows their results to be integrated

• have a realistic roadmap to manage expectations across customers, business and technical teams

• manage quality of implemented solutions to ensure service, customer experience and future maintainability

Of course, properly chosen and employed, AI can help with many of these!

Zero CRUD* with Domain Models and Patterns

Many organisations still have armies of developers grinding away writing Create, Read, Update, Delete (*CRUD), enquire and report user interfaces and business logic - even in “Agile” projects! With a complex domain model, it can easily consume more than 60% of project effort. Indeed, some administrative systems are nearly 100% CRUD!

One solution is to resort to low-code or no-code tools, but organisations resist them for a variety of reasons, including lack of standards, limited skill availability, strategic risk and the fact that many of these only work well in narrow use cases.

It is really important in stakeholder facing applications and websites to have really good user interfaces, so what to do? One solution we have practiced for over two decades, and adapted for the web and mobile, is to have a domain driven user interface which exploits patterns for the commonly required functions.

Patterns consist of UI code templates which provide layout, controls and common business logic. They have placeholders where the specifics of the entity / concept to be captured, edited, updated or deleted etc. are plugged in. The domain specifics (Concepts, Relationships, Properties) are provided to the application as models which are accessible at generation or run time.

For statically bound environments (e.g. C++, Java, C# etc.) the customisation of a pattern with domain specifics can be done at compile time. In effect many interfaces conforming to the pattern are generated into the production application. For dynamically bound environments (e.g. Smalltalk, Python, JavaScript) the generation can even be done at runtime, effectively serving the code to the client where it will execute through interpretation.

This approach has numerous advantages, including:

• Major reductions in code base size and hence effort in development and maintenance

• Consistency of user interface and logic produced across developers and applications

• Higher quality since the patterns can be developed by expert developers and thoroughly tested

• Reduced time to market and greater agility. In the case of late bound environments it is even possible to extend the domain model at runtime and have the interface adapt immediately without any deployment

• Massive reductions in effort when user interface refreshes are required (e.g. the latest / greatest JavaScript framework makes a new style “required”)

If you would like to see a talk and demonstration of this in action, you can watch the video here.

If you would like to skill up on the latest in Application and Solution Architecture thinking, take a look at our upcoming course: Techniques and Deliverables of Application and Solution Architecture.

#agile #SolutionArchitecture #DomainDriven #SoftwareDesign #Patterns

Agile Process or Artefact?

There is much hype around Agile these days. We know that things are moving faster than ever and that “slow business is no business”.

There are agile methods, agile techniques, agile projects, agile best practices, agile coaches and agile certifications. But how many agile businesses are there?

I support the original tenets of the Agile Manifesto and the teachings of the founders. They highlight user involvement, refinement through iteration, communication, flexible working and trust relationships between business and technologists. All good things.

I do have a problem with agile dogma and religion in the absence of other essentials for Agile practices to work. These essentials include: high skill, small teams, continuity of resources, trust and attention to quality and testing. Agile should also not be used as an excuse to bin architecture, requirements definition and documentation.

I often see Agile abused to “crank the handle harder” in development projects in an attempt by business to get to functional goals earlier. The emphasis here is wrong. We don’t need a more pressured process, we need a better result: higher quality (better matching requirements) and more adaptable to future requirements.

Using a building analogy, many Agile projects are “laying bricks faster”. This may be without fully understanding requirements, proper design for safety, scalability and still creating a “fixed” artefact, namely a brick and mortar building. If requirements change, as business evolution dictates they will, another project is required to break down elements and build others.

I suggest we should be building more flexible artefacts. Take a conference centre, which must host a sports match one day, a book fair the next, on the weekend a rock concert and the following week a motor show. We know it has to be flexible and that we won't have time to rebuild. Flexibility is thus a stable requirement. Knowing that, we can design and build for it, even using a conventional construction approach. We can build a shell with large open, reconfigurable spaces, movable walls, power outlets in the floors, lighting on tracks, etc. This will allow the user community to alter the building themselves in a matter of hours.

We need Architecture to identify high level stakeholder requirements and change dimensions and try out conceptual options rapidly, partition elements that can be tackled by separate teams with defined interfaces and then to guide implementation. The construction itself could be agile or conventional. The former offers advantages where some requirements and suitable solutions are not known and need to be tried, prototyped and refined. Using an Agile approach requires high skills, stable teams, continuity of resources as well as a high trust from sponsors.

The solutions should be documented so they are easily used by the operators and maintainable for adaptation.

#Agile #SolutionArchitecture #EnterpriseArchitecture