Services
Architecture in the core of solutions
Solutions architecture work in all its forms is in the core of Hoijan. Our skills extend all the way from business architecture to implementation and everything between.
Building true digitalization (not just seemingly digitized services), regardless of the business area, starts from the understanding of needs and current situation. Through this understanding it is possible to create the target and the priorities for the improvements. It is most important to understand where we are and where is it that we want to go. Everything does not have to be done at once.
In a complete solution, the core is build around commercially available solutions but almost always they also require some specific integrations in order to get information flowing properly through business functions.
The areas which are in the core of company's competitive ability must be given special attention and often fully customized solutions are the best approach. Putting effort to implementing custom solutions to functions where company cannot be no different than any of its competitors, does not make sense. Investments should be targeted to the areas where company can positively differentiate from its competitors. One should apply same critical evaluation to IT solutions as one does to any other investments in the company - expenses in mind, looking for the competitive advantage.
Over the years we have noticed that regardless of the business area same principles apply when it comes to digitalization. Ultimately all organizations are aiming towards the fluency, reliability and consistency in information flows, targeting to achieve efficient and predictable operations. Our experience and technical skills in the areas of industry, fintech and public sector as well as overall understanding of the special characteristics of these sectors, are in the core of our services.
Architecture
Creating the vision
Building up a vision starts from the understanding of business objectives and current situation. Fairly often there can already be a good understanding of the goals, achieved for example by a preceding business design work, and then this is now taken further into practical plan.
Ultimately the target of this work is to understanding what all this means from the existing systems perspective. Most natural approach to this is to first identify and design all the information flows that are needed to make everything work. On the same time the problem areas and systems start showing up, pointing the work towards the areas which require most attention.
The information flows create the base for the overall solutions architecture and especially for the delta compared to the current situation. If something already works well there is no point to change it just for the sake of changing, unless of course there are some other requirement which will direct towards a greater change to be done on the same time.
As a result, a development vision is created and documented, extending over 5, or even 10 years into the future. Naturally long visions needs to be revisited occasionally to keep the plan fresh.
Technology
Scouting and selecting solutions
It is not rare to encounter rather old and even outdated solutions in our work. Any renewal project is also a good moment to educate oneself with latest trends from own business area. Available new technical solutions give surprisingly good view also towards the ongoing and even upcoming trends in the field. This crystal ball is definitely worth looking into even though own development project might be a lot more limited at that time.
Scouting solutions is an excellent opportunity to learn new and this phase is such that in addition to technical experts, also business representatives and end-users should be involved.
Solution scouting proceeds typically from a long candidate list to a short-list, and further to more detailed discussions with the a couple most appealing options. Demos and possibly POCs (Proof-of-Concept) are also used to increase understanding before the final price negotiations.
During this process previously unrecognized system potential is found as well. This will be used to to further improve the previously created development vision. Quite often the potential exceeds also the original targeted business area and thus the learning opportunity cannot be emphasized too much.
As a result of this phase integration needs as well as other changes are well understood. During the selection process architect often has also the important role of work estimation and planning the project phases.
Projects
Guiding through the transformation
Good plan is not worth much until it is taken into reality, to be part of the operations.
Generally our goal is that the organization that is going to be using the solution takes also the leading role of the transformation project. Having said that, sometimes also the fully detached guidance may be necessary. It is anyway very important to take the expertise and experience from the organization to full use so that all the last details are also detected and taken into account in the new operating environment.
Architects role during the transformation is typically to support and steer work from technical and functional perspective towards the vision. “Study” and “decision item” techniques are some of the methods that can be used to manage changes during the transformation.
DevOps
Automating delivery pipelines
Modern development model is targeting to automate as much as possible when it comes to development and maintenance of solutions. During development version control and CI/CD pipelines ensure efficient parallel work whether it is related to integrating commercial solutions or custom software development.
Architects are the experts on the target and therefore they are also a good help on planning the development and testing environment. Goal is to ensure solid environment also for the post-project development when often all the originals experts have already moved to new duties.
Solution design
Designing interfaces and software
Even though often architecture work is considered to end when the overall plan is in place and suitable technologies have been selected, often customers want that architect take planning at least one more step further in order to guarantee smooth knowledge transfer all the way to the implementation.
Modern solutions are build around “api-first” thinking which give a good approach on ensuring excellent integration capabilities also beyond own solution. Well designed interfaces also help on keeping the development modular so that each entity have clear and accurate responsibilities.
Responsibility on the software development should be on the development team as much as their skills allow. Technical architect supports the development team and has often also a role on “growing” necessary skills to the them if they do not exist already. In modern agile development style software design is done continuously ahead of the development so it is definitely always more support than separate isolated design work.
Implementation
Taking the lead developer role
When software design is done using the agile methodologies it is quite natural to use architect also as a lead developer of the project.
Lead developers responsibility is to ensure defined architecture is followed but on the other hand also bring improvement ideas and possible problems from development to architecture. It is only natural that an architect would also take lead developer role as it speeds up decision making on the smallest details. Having said that, it is good to keep in mind that architect should keep away from the smallest details in order to keep the overall vision crystal clear.
After-care
Systems analytics and caretaking
Development projects are entities with a start and an end. Once a project is finished the experts typically move on to next tasks which means that most certainly some information will get lost. Good architectural documentation guarantees relatively good continuity but it can be enforced further with regular architectural reviews. During the review, current situation is compared to development path and as a result adjusting the path and target as necessary.
Similarly organizations may have ended up in situation where it is not very well even understood what the current situation is, meaning that preparing for the future is not possible either.
These are examples where our architects can do one-off or regular situation analytics together with action proposals.
Analysis
Technical due diligence analytics
Business mergers are critical time for both parties. Especially if functions are planned to be merged, ensuring the technical perspective is very important. Functions can unfortunately often remain separate simply because technical enablers fail to integrate or merge. Good predictability for the future can be achieved by adding a technical DD as part the normal DD procedure.