What comprises a “Solution Architecture”?

A solution is a combination of components in a configuration that solves a problem or exploits an opportunity in a way that meets our goals. Hopefully it is also effective, efficient, sustainable, ethical and relatively risk free.

It is not just a software system, but rather a combination of software, process, people skills, data and technology that meets business, human, technical and legal requirements.

Considering the provided rich picture:

The items outside the circle represent the context in which a solution is developed. We ignore these at our peril. If we do not know the Business Goals for a solution, we can only meet them by extraordinary luck. If we do not know the Legal constraints we will run foul of the law. If we do not understand the Customer and the Stakeholders, we are unlikely to provide something they are happy with. If the service is not delivered via the required Channels or compatible with the Brand strategy, we may miss the mark entirely. In short, many of these should inform our Requirements. Alan Kay famously remarked: Context is worth 80 IQ Points.

Our requirements should also certainly include the Functions that must be performed, the Business Objects (Data) that is used, the Technology we need, the Process to deliver Value, the Application Services we may use or provide, the User Interfaces, the Events we need to respond to or generate and the Locations where we need to be available.

Non-Functional requirements will also play a major role in the viability and success of a solution. These include aspects such as security, reliability, performance, cost, maintainability, flexibility, ease of use, compatibility and many other factors.

Customer Experience is crucial to ensure wide and willing acceptance and delivery of business value. Staff experience is also key, as it that of other professionals who will deal with the solution, including Operations, Support and Maintenance staff.

The Solution Architecture should follow some important principles, including: Modularity, loose coupling, message based communication and open standards. Its also good to have tests built in and automatically repeatable, an affinity for DevOps or Continuous Deployment. User interfaces that are intuitive and built in tutorial aids are really important too.

A cost effective system might be composed of off the shelf components, reusable library elements, configurable components and custom developed elements. The solution includes these and the other elements of human skill and capability, supporting technology, infrastructure, documentation etc.

We may also need to contemplate the development/ implementation dependencies and partition the solution into an initial Minimum Viable Product plus one or more incremental delivery releases to get us to the full capability required.

Solution Architecture is a challenging but very rewarding role.

#SolutionArchitecture #Architecture #Requirements

Just one API?

GraphQL provides single query for queries and updates

Jargon buster at the bottom of post.

First came RPC to call a function across a network. But it was language specific and lacked standard facilities. So DCE was made to address common requirements, such as directory services, time, authentication and remote files. But it was not object oriented when Smalltalk, C++, Java et al arrived. So Microsoft devised DCOM to provide distributed services for Ms languages while others backed CORBA which provided cross platform and cross language services. Both required agreement for message formats ahead of time.

Enter Web Services, leveraging XML to serialise data, WSDL to describe services, UDDI to publish, find and bind to them, and SOAP to message remote objects. Great! We could now find, bind to and invoke services without prior design agreement. But, it was not very efficient and required a lot of plumbing on each end, and quite a bit of knowledge from developers.

So, Roy Fielding devised REST exploiting HTTP to provide a simple way of working with remote Resources. REST allows us to simply access remote servers and retrieve something GET, inform about something POST, store something PUT, update something PATCH or delete something DELETE. This is achieved by creating simple headers and a request line including the URL and parameters. Post also has a body.

REST is very light weight and does not need much infrastructure. Combining it with JSON made it very easy to use from within web pages and mobile applications and it quickly took off.

But there was a problem. Each REST request would get a specific thing from the server. If there is a rich database or knowledge graph on the server, we can create many REST APIs: At least one for each kind of domain object (e.g Customer, Product, Account, Invoice etc. ); Often more than one to cater for different application requirements (partial records, related records etc. ). Plus we will have different APIs to query, to store, to update etc. So, a server with a database managing a score of domain concepts could quickly require 100s of APIs. Ew, that’s a lot of development, testing, deployment, documentation, maintenance…

Facebook ran into this problem at scale. Their solution was a query language that would live in the server as a single entry point and receive a query request as a parameter. This is not dissimilar to the way a relational database receives dynamic SQL requests. Now the tailoring of a response can happen in the server (more efficient) and we have only one API endpoint to maintain. Voila. So that solved the problem for Facebook… Fortunately, they published it as GraphQL which allows writing query and update (mutate) statements and having these fulfilled by a suitable GraphQL processor / application / database on the server. Initially, these were discrete, but they are starting to be embedded in database systems, especially Graph Databases. One good example is DGraph.

Get started at: https://graphql.org/code/
More info at: https://graphql.org/learn/

JARGON BUSTER:

You can also find good explanations of most of these topics on Wikipedia

• RPC - Remote Procedure Calls

• DCE - Distributed Computing Environment

• API - Application Programming Interface. A way of requesting a service or function contained in another piece of software. Most commonly used today to refer to a REST API

• COM+ - Microsoft Component Object Model. An architecture that allowed sharing of objects between Microsoft languages.

• DCOM - Microsoft distributed COM. Similar to COM+, but allowing objects to be remote

• .Net - Microsoft Component model and framework that succeeded COM and DCOM

• CORBA - Common Object Request Broker Architecture. An architecture for distributed object messaging across languages and technologies.

• Web Services - A set of standards, leveraging XML, that allows requesting services across the Internet. Includes WSDL, UDDI, SOAP.

• XML - eXtensible Markup Language. A standard for encoding data onto text with specific tagging of the meaning of the values.

• WSDL - Web Services Description Language. An XML document describing a Web Service.

• SOAP - Simple Object Access Protocol. A way to invoke a (remote) service in the Web Services approach. Effectively an XML message requesting a given service and expecting an XML response message.

• UDDI - Universal Description Discovery and Integration. A protocol for publishing Web Service Descriptions and for finding these.

• HTTP - Hypertext Transport Protocol. The protocol of the internet which allows hyper-linking.

• REST - Resource State Transfer protocol. A protocol that leverages the HTTP intrinsic functions to support requesting services across the Internet with minimal other infrastructure.

• JSON - Javascript Object Notation. A way of encoding JavaScript data structures on to text for transmission or sharing. Similar purpose to XML, but lighter weight.

• GraphQL - A query language used on a client and interpreted in a server which allows easy retrieval of data using graph concepts (Nodes, properties and relationships).

• RDF - Resource Description Framework. A standard for defining facts and knowledge using simple statements with a Subject, Predicate, Object format. Part of Semantic Web standards.

• DGraph - a Property Graph database that supports graph schemas, RDF, JSON and GraphQL natively at web scale. Also does ACID transactions.

• ACID - Atomic, Consistent, Isolated, Durable. Desirable attributes of transactions in a database.

#API #Services #REST #WebServices #SolutionArchitecture #Design #GraphQL

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

The (Enduring) Value of Great Design

Prepping for my upcoming Techniques and Deliverables of Application and Solution Architecture course, I watched a video by the UX guru Jakob Nielsen talking about UX 2050. The future predictions were interesting, but what was more interesting to me was the information about the empirical work and iteration that went into the design of the humble telephone touch keypad by Bell Labs, way back when. They researched many models of keypad with different layouts, sizes, shapes, etc. They surveyed potential users, but they also empirically tested many models before settling on the final design. Nielsen estimates that the design has been employed 40 trillion times and has saved the world some 1 million person years of time! Would that some of our current web designers would take note!

On a related theme, Apple hired a Masters graduate in physics and computer science to work on the scrolling of lists, their acceleration and “bounce” at the bottom and top for IOS. This was an effort of some three plus months for a very qualified individual. Sounds crazy, but the lists behave beautifully, intuitively and feel natural. Just think how many times somebody, somewhere scrolls a list on an IOS device and you get a sense for how much this design attention has paid off. 

Staying with the Apple theme, after watching the World Wide Developer Conference (WWDC) for 2021 last week, I again came away with the conviction of how much good design contributes and pays off downstream. Consider Unix (also, originally, from Bell Labs), which was taken up in academia and evolved into the Mach kernel paired with the Berkeley Distribution (BSD) OS, which Steve Jobs and Next used as the platform for Next Step, which later evolved into Apple’s System X, now MacOS, but is also the foundation for iOS (on the iPhone), iPadOS (on the iPad) and even watchOS on the Apple Watch and tvOS on the Apple TV.

WWDC showed a variety of examples of how the unified concepts underlying these systems facilitate advanced features, such as seamlessly controlling apps across multiple devices in proximity with a single keyboard and mouse (Universal Control); The Notes App which is available across the family and supports quick note taking, handwritten notes, capture of images, task management, cloud syncing, attachments, maps integration, tagging and more; the Live Text feature allows recognising text in photos and images from various sources, including device cameras, websites and image files. By the way, it is 20 years ago that Steve Jobs returned to Apple and the company bought Next Step to form the basis for the next generation of Apple operating systems. 

Bottom line: It’s worth the effort to create great design, which is functional, human centric, efficient, durable and elegant. It pays off handsomely in the long term.