Architecture is a product and a process. The product maps the various components and their relationship to the department or organization. Components may be systems, as well as manual and automated processes, roles that carry out the processes, or data in systems and on paper. The architecture provides a description of the current situation of the organization, a description of the desired situation and a roadmap showing how to achieve the desired situation. Read more.
Architecture FundamentalsView all Architecture Fundamentals coursesAgile ArchitectureView all Agile Architecture coursesDesign & ModellingView all Design & Modelling courses
There is a panic. The supplier of the main IT system of your organization indicates that support will end because the underlying technology is outdated. And this system has dozens of links with other systems. Or maybe there is no panic, but implementing changes to IT systems is slow and the systems no longer contribute to efficient and enjoyable work for employees. Or perhaps the systems run fine, but the organization would like to know better how to respond to what customers actually want. This kind of problems are often not limited to a single system and a single business process. Therefore architecture takes an entire department or organization into account, incl. the strategy, processes, responsibilities, information, systems and infrastructure.
What is architecture?
Architecture is a product and a process. The product maps the various components and their relationship to the department or organization. Components may be systems, as well as manual and automated processes, roles that carry out the processes, or data in systems and on paper. The architecture provides a description of the current situation of the organization, a description of the desired situation and a roadmap showing how to achieve the desired situation. But because of continuous changes of the organization, its objectives and strategy, but also the technology and the environment, the product architecture is also constantly evolving. This continuous development is addressed in the architectural process.
With architecture, you can ensure that your business processes and information can actually contribute in the short and the long term to what you want to achieve as an organization. Suppose your organization wants to be agile and be able to change rapidly, this will have consequences for the knowledge and skills of employees, the way they carry out their work and how IT supports them. Suppose you need to ensure the organization absolute security and robustness (think eg. of building airplanes), then this will have consequences for the structure of your organization and information. Architecture helps to make the right decisions in this set up. When your make decisions without architecture, you risk suboptimal decision-making, with a tangle of applications (for every problem a separate system) and thus the inability to adapt IT systems (fast), cumbersome processes (many workarounds), and higher costs.
How to develop architecture skills?
We recognize many types of architects. Thus one speaks of domain architects, business architects, software architects, information architects, data architects, infrastructure architects and so on. At Capgemini, we distinguish broadly two types of architects: the enterprise architect and the solution architect.
The enterprise architect is responsible for the architecture of an entire organization. Or for a particular domain within the organization, then we call him or her a domain architect. He or she should be able to translate organization strategy and objectives into the daily processes and information, into the relationship between them and into the best way to achieve these processes and information. For this purpose, a starting enterprise architect already has knowledge of business and information analysis and is skilled in advizing. Further development is needed in architecture methods, business and information architecture, security, facilitating workshops and concise communication. Experienced enterprise architects also should familiarize themselves with the role of the enterprise architect in (agile) IT development, project management, change management and influence and persuasion.
The solution architect is responsible for the architecture of a solution. That can be an IT solution, business solution or both. Often, but not always, these solutions are realized by projects. Therefore, the solution architect has a close relationship with the project. He or she should be able to translate objectives, such as solving a problem, into a solution that fits within the enterprise architecture. For this purpose, a starting solution architect already has knowledge of information analysis, of IT technologies and software development and should be skilled in advizing. Further development is needed into architecture methodologies, information architecture, solution design and development, security, facilitating workshops and concise communication. Experienced solution architects also should familiarize themselves business architecture, trends in technologies, project management and influence and persuasion.
External influences such as digitization and disruptive business, but also internal initiatives such as the radical transformation of old IT landscapes motivate organizations to fundamentally change their business and revenue models, and the complete underlying operations.
Coherent design of business processes and information to perform transformations successfully is therefore a growing challenge for many organizations.
To answer these questions, Capgemini has developed the Enterprise Design approach that offers, right from the start, an overview in terms that appeal to executives and managers, and that ensures co-creating an integrated Digital Transformation from a vision shared by all disciplines involged.
The three day Enterprise Design Foundation course gives an overview of the steps that are part of the Enterprise Design approach.