Practical EA

Single-sign-on (SSO) is a critical component in large enterprise architectures, either from security prospective or usability of systems. There are many different approaches to implement SSO functionality, the most common is the Windows domain authentication based approach, but that has many limitations while it is still plausible and useful for many of the companies. The limitations we should highlight are the platform limitations (desktops are fine, other devices are so limited) and extendibility (multi-factor, user profile data access). All the steps you will read are the summary of a living project executed in a large company, it was not only a l'art pour l'art activity of a boing architect.

This article describes an alternative solution, using OpenID Connect protocol, utilising Windows authentication, supporting different platforms and user channels, handling multi-factor authentication and so.

The perpetual question for enterprise architects is, which is the best enterprise architecture management tool. I have my favourite based on the past years experience, which I selected after a careful analysis of potential candidates. One of my clients requested a comparison between two tools and I would share the results here. Shortly the two tools are SAMU from Atoll and EA from Sparx. The summary of the comparison is, that they have to exchange the name they have! SAMU (System Architecture Management Utility) is a real enterprise architecture management tool, with all necessary aspects, while EA (Enterprise Architect) is a great system design tool, with very limited capability to be extend to enterprise wide repository.

Referring back to article The structural strength of steel, I will share some practical examples to encourage architect colleagues to break out of the role of „boxes and lines“ - which is usually expected from us. All of us should know stones and bricks what our architecture is built from - still should not be the best bricklayer, but even not the worst!

This first article is an infrastructural task, building a Redis cluster in well-controlled Linux environment on a RHEL7 host.

Without competition, the things will not improve. On the other hand multiple parties in a competitive situation may cause different problems. Let's go through these issues and get some tips to handle them.

If you never met this question you are living somewhere else but not in the IT industry! Here I collected some practical examples you may refer to when facing the question in the title. Here at the start my position about rules and principles: freedom is made by great rules and this is a basement to maximise ability to change! This article is the continuation of Rules and exceptions article.

We reached the next staged to make Reactor to be more simple to demonstrate. Till now, it was possible to try it out through Swagger-ui and a chatbot, but from now on you can play with a browser based responsive UI to learn about Reactor. This UI enables all operations about cart based service manipulation: open a cart, order or remove product offerings or drop/commit a cart as you wish.

Waking up at the morning and checking how Reactor demo environment is, I recognised the setup of Santa Claus present and birch. Not only do Santa exists but he follows novelties!

In the last article you read about our project experiences using OpenAPI. Here you can learn about the target we had and the product we implemented. On the top of the information, you gain a demo access to the solution too what we call Reactor.

Reactor was made to serve each type of front-end applications, who want to handle multistep service manipulation carts. The interfaces have sophisticated data structure to minimise the API requests, like an add operation can respond with the new CurrentPortfolio state of Reactor transaction together with the update AvailableProductOfferings list. Other it is fine for many applications, others require simplified interfaces having predefined standard response structures. One example is chatbot.

We may say that OpenAPI is the latest craze on the field microservices. Otherwise it is also true that this specification helps a lot to implement standardised APIs. We gave it a try to implement our new portfolio element interfaces on OpenAPI basis and this article is to share to you our hands-on experiences. The results of the development, where we collected the expereinces below, will come soon.

The last article about the discussion of two "black-belted" TOGAF architects about the nature of architecture management finished by the words of "A good building architect needs to know the structural strength of steel before they design in it," Let's see some practical examples of 'steel' together!

Like great archers we have the right tool (the Bow), the models and processes (the Arrow) and the experiences (the Training). All the things needed for Architects is ready in our Archery program.