Assessing and mapping the current status of an organization, usually called AS-IS, is the starting point of most architecture projects. However, this practice has been proved to be unsustainable.
To justify this approach, people usually use arguments such as: “To evolve it is essential to know where we stand”. Although wise, this argument is no longer suitable in the current fast pacing and constantly-changing world.
Organizational change is increasingly faster and transformation cycles are becoming shorter. However, the perception that this fact enables a more pragmatic and simple approach to the problem of Enterprise Architecture, is commonly ignored.
The previously mentioned assessment phase, and loading the organization current status into a repository or knowledge base, is probably one of the most critical steps in an Enterprise Architecture initiative. This is true, because there is a strong probability that the information collected after finishing the assessment, is already outdated against the reality in the organization. Since this AS-IS assessment is always rather complex and demanding in terms of effort, the thought – or in many cases the certainty – it will soon become obsolete, is a strong argument against an initiative for an Enterprise Architecture project. This is perhaps the main argument of the unbelievers on the benefits of Enterprise Architecture.
Before entering the globalized age we experience today, the flow of information, as well as the pace of organizational change was slow. Transformation cycles last for 5 to 7 years, which enabled an AS-IS assessment useful and valid for at least 2 to 3 years. With the transformation cycles rapidly being reduced, the AS-IS assessment validity is being reduced at the same rate.
We live in an age where what is new now may become obsolete tomorrow. And the same applies to information used for decision making in organizations. The increasing speed of transformation cycles, make AS-IS detail increasingly more irrelevant, so there is less and less need to conduct a detailed assessment of information that reflect the current reality of the organization.
As an example, let’s consider na organization that is planning starting transformation projects within 6 months, and that until then must complete the ongoing projects. In this case, what is the relevance of AS-IS for planning initiatives that will start within 6 months? In fact, the greater the change resulting from the ongoing projects, the lower the accuracy of information currently collected. After 6 months, the AS-IS initially mapped, will no longer mirror the reality of the organization and will not be liable for decision making.
As an extreme, let’s imagine that the ongoing projects would change the entire organization. In this scenario, planning actions to start within 6 months would not require today’s AS-IS, but the TO-BE resulting from the ongoing projects. Better saying, they would need the integration of these two visions, and that is the challenge for Enterprise Architecture in the changing organizations.
Taking last article’s topic, the ability to automatically generate representations/models of the organization is na essential tool for mitigating this problem. We can then extract the information from TO-BE models manually produced by the teams of different projects, and automatically generate an integrated model representing the future reality of the organization according to the completion of ongoing projects.
Comparing to physics, the higher the speed of a body is, less relevant is its position at a given time. In Enterprise Architecture, the higher the speed of transformation of the organization, less relevant is its AS-IS.
Fortunately, assessing what projects are currently implementing (and that will be the immediate TO-BE ) is substantially simpler than to assess what was done in the past, and for what no one really cares. But this will be the subject of the next article
Article published in portal Profissionais de TI
It is common thought to consider that Enterprise Architecture involves the manual modeling of the various sub-architectures, namely through the use of modeling tools. Such a scenario is somehow scary because it means any change or development in the manually created model will require a manual effort for changing that model.
However, manual modeling is only suitable on the first stages, when a design is created from scratch. In fact, modeling existing artefacts in an organization can be done automatically based on text information collected from different sources of information within the organization.
Even if those information sources are not updated, which happens quite often, the procedure should be update those sources and then generate models, instead of taking a modeling tool and start creating models manually. The immediate outcome might be faster, but on a medium and long term, manual modeling is an untenable situation for organizations.
Thus, Enterprise Architecture tools must have the ability to generate graphic models from information imported from different sources of information within the organization, such as, excel sheets, CMDB, service catalogues, applications, processes, etc.
When a Project of Architecture to Basel is started, what we see mainly is a large volume of information diffi cult to manage and from where extract any result for auditing. It is common that each area has its own language and information silos don’t cross and don’t show the changes made by running projects. Projects are elements for transforming the organizations, so their results lead the progress of the corporate knowledge base, which are generally maintained manually in different Excel sheets. This mean that updating them according to results from projects is an extremely complex and time-consuming process.
In this Brazilian fi nancial institution, besides scattered data in Excel files, the standardization of information and reports generation was slow, exhausting and delivered inconsistent results, placing the goal of Basel project for the bank at risk.
Aitec Brazil mission was to design, plan, and implement, in 7 weeks, a tool for extracting results for a Basel audit, with information concerning the bank’s IT, and financial area, with an integrated vision of architectural vectors. More specifically, it would be possible with this tool:
• Identify the items related to systems of Market Risk, target of Basel II;
• Have an integrated and updated view of businesses As-is and IT architecture, by consolidating information from diff erent sources;
• Have the ability to extract quickly and reliably the most diff erent views to Basel II audit.
Surely that part of the challenge was to clean, structure and import information from different areas for generating the required views for auditing.
In 30 days, the goal was to import information from a corporate repository and run a solution for automatically generate outputs: PowerPoint reports, architecture maps, and graphics for time analysis
• The approach we used was designed to minimize the main risks of the project:
• Time spent with the defi nition of the knowledge base metamodel.
• Unsuitable detail level of metamodel facing information sources. Metamodel complexity must meet the immediate needs and the existing information sources.
• Time spent adjusting manually unstructured information.
• People could lose confi dence in the project if no short-term results were presented
• Audit could not receive information that didn’t mirror the bank’s reality.
The structure to solve this problem was a joint solution from IBM – Rational System Architect and Link Consulting – Enterprise Architecture Management System (EAMS).
System Architect was primarily used as knowledge base. The integration of information and generation of updated architectural views, was achieved via EAMS.
The challenge to create a representation of corporate architecture amidst a project that requires speed and reliability generates more risks than those normally found in a cautious Architecture
initiative. The initial goal of providing real information to the audit was successfully completed in 3 months, but to keep the representation alive/updated is an even greater challenge.
This case confirms the role of Corporate Architecture as a tool for organization change and fast compliance with regulations. We have currently, besides the successful project within Basel, a platform providing information for managing requests and impact analysis, streamlining the creation, maintenance and evolution of the corporate strategy.
— Pedro M Sousa —
Our newest paper has just been published following its presentation in 4th Working Conference, PRET 2012, Gdańsk, Poland, June 27, 2012.
The IT industry is flooded with various terms with more or less obvious meaning; however, in the absence of a strong and precise concept definition, the terms can become the source of confusion and lack of understanding in many of the organizations. Especially terms such as application, information system, and business solution tend to be used indistinctively in various scenarios. The existence of an application/system/solution catalog is common in many organizations and it is considered a fundamental element that draws attention from the Business, the IS and the IT area. This paper presents a case in which a financial institution considered the need to clarify the Application concept in order to address the problems surrounding an application catalog composed by 500 so called applications. The paper introduces both the taxonomy fundamentals and the recognized benefits. As the result, and considering the coverage and generic nature of the problem, we consider the outcome considerably reusable
Available at: Springer