Making the right technology decisions for your business today and in the future can make the difference between success and failure. We live in a world where change is moving fast, technology is ubiquitous and systems are becoming increasingly complex. The role of the solution architect has never been more important.

My role is to understand needs, give advice, manage risks and deliver the right technology results. It can involve working closely with business decision makers, business architects, business analysts, project teams, supplier representatives and countless other roles. This is about communication. My job is to listen, empathize, explain, advise, influence and negotiate.

As a successful architect you have to have almost uncanny ability to know what to do in almost any situation. This is because they have normally been involved in a wide range of technology, organisation and industry scenarios. Certainly there are very good technical specialists who understand a certain technology down to the unimaginable detail, but I see the advantage in my experience and thus the range that allows me to create added value in a variety of business, project and technology situations.

Recently, some examples of organizations have been seen that have experienced difficulties due to technological problems such as security holes, calculation errors and system failures during high utilization. As a solution architect, you are responsible for helping companies deliver technology solutions that avoid these dramatic events. A good architect understands what technology has to do and will minimize the risks that could hinder the technology that meets business requirements. Therefore, I pay great attention to non-functional requirements such as usability, reliability, performance, support ability and security in connection with risk management activities such as performance tests and security tests.

Solutions for companies are not one-dimensional and I am known to use a so-called “helicopter view” to get the overall picture of what the organization is trying to achieve and what business processes it is using. At the same time, of course, I am concerned with special features such as interfaces, data, input / output management and other trouble spots.

Being pragmatic is particularly important. As an experienced solution architect, I understand requirements very well and am very adept at separating the wheat from the chaff, using what is valuable and discarding what is worthless in the given context. Regardless of this, I give my clients the right advice for the desired business result. This can mean that you are firmly committed to a decision and are not convinced of sales hype, product requirements or crystal ball. But that can also mean telling organizations the hard facts they may not want to hear.

An essential part of defining the solution architecture is understanding and addressing the concerns of the most important stakeholders. In my experience, I see three areas here.

Senior Management – Increase productivity or reduce costs
Users – Streamlining daily activities
IT Support – Providing a secure, stable and sustainable environment

As an architect, it is not always easy to reconcile the needs of all parties involved and to implement a solution that achieves the desired business result. You may think that architecture involves a lot of detailed modeling and documentation, but in reality I spend most of my time taking technical direction. This means advising the various interest groups on issues relating to the solution to be implemented. This can cover a wide range of topics, from technical design and development methodology used to assessing the impact on the business that certain technical decisions may have.

Effective technical leadership requires a comprehensive understanding of information technology and the provision of solutions. Leadership means working across business, applications and infrastructure. This does not mean that I am an “all-rounder” as a solution architect – on the contrary, it is the deep technical knowledge that I bring along that the project participants rely on to make well-founded decisions. Very often my ability to apply my technical knowledge and experience from more than 22 years of experience and continuous further training is decisive in solving broader, cross-project problems.

Finally, it is important to understand that I do not have to play a formal role, but that decisions about architecture are always made consciously or unconsciously. Compromises between functionality, system properties and costs cannot usually be avoided.

Benefit from my many years of experience and let us arrange a non-binding meeting.