Do enterprise architects need to be familiar with Agile methodologies?
Although most enterprise architects are becoming an integral part of project scrums, their participation is largely limited to ensuring that Agile teams are made aware of the strategic intent of the organization and the as-is availability of support mechanisms. The design team should be limited to the gap between as-is and to-be rather than re-inventing the wheel.
Any design considerations made by the team should be approached with four main thoughts in mind:
- Internal to Internal Implications (Department to Department)
- Internal to External Implications (I.e., Organizational Service to Customer)
- External to Internal (Regulatory or Compliance)
- External to External (Regulator to Government Department, SDGs ETC.)
It is not only an IT solution but encompasses product pricing impact, risk aspects, data requirements, skills shortage, vendor support structures per location, regulatory requirements per location, etc.
Agile was originally brought to life as a software development approach, and so my findings are that it is a personal choice as to whether the Enterprise Architect becomes certified in Agile methodologies or not, but the ability to govern outputs from an Agile team is something that is non-negotiable.
With the growth of digital and IT, has EA knowledge become relevant to a wider number of roles?
Digital transformation without business architecture insights is one of a number of reasons IT projects have such high levels of failure; deploying the latest IT new shiny tools without understanding where the manual aspects of the organizations require help is a recipe for disaster. The ability of the architecture team to identify the areas where digital transformation is required to meet strategic goals and objectives will ensure a greater chance of success in meeting business requirements. IT staff, on the other hand, see EA as a subset of their reporting line, and countries such as the USA still see EA as only IT-related, with the business aspects being ignored.
But, to answer your question, it is critical that EA knowledge becomes relevant to a much wider spectrum of the business to achieve agility.
What are the most disruptive elements in enterprise architecture? Has this changed in recent years?
The recent adoption of Agile methodologies has convinced solution architects that there is no need for EA or Business architects as they can meet with business executives and design solutions. However, the lack of knowledge on both sides of this discussion has led to an increase in miscommunication and a lack of understanding of the specific implications.
Without an architectural translation layer between both parties, the result has been instrumental in producing a bad reputation for architecture as a whole. As mentioned in my presentation, TOGAF needs to understand the difference between organization and enterprise, with the latter requiring an increase in scope for architects.
What will be the key to the success of TOGAF 10?
The success of TOGAF 10 and beyond will be dependent on further analysis of the ecosystem within which the organization plays. Prior to 10, very little attention was given to the external impact on an organization and strategies to ensure competitiveness. TOGAF 10 has delved into this subject, but much more work in this regard is necessary if TOGAF certification is to remain relevant.
Do you feel enterprise architecture is adequate for the current state of banks and the financial sector?
I do believe that EA is adequate, but two potential shuffles may increase the acceptability of EA as a trusted advisor.
- Business architecture is destined for a role within strategy & planning, as it currently has an extremely limited role from an IT perspective.
- EA, in its more traditional IT role, would act as the conduit between strategy & planning (Including business architecture) and design solutioning teams.
Who can benefit from studying EA in banks?
Five main roles can benefit from EA in banks:
1. Programme Management
2. Business Analysts
3. Risk Management
4. Financial Management
5. Product & Service Management
The completed repository could also be utilized for employee onboarding in a given department or in-house training & development programs to reduce external training provider costs.