In a post I have shared my notes on Enterprise Architecture basics and concepts mostly from TOGAF perspective and definitions which I recommend having a look on that prior reading this post.
To sum up, EA's goal is to increase project success rates by providing sufficient planning materials, reduce response time to business changes by implementing new business capabilities, and finally eliminate redundant activities by providing or becoming a one-stop shop for enterprise constraints and being connected to actual work on the ground.
The fact is while many businesses are still figuring out what EA is, what it does, how to measure its success, and so on, some companies believe it is time to reinvent EA to offer more solid values.
Here I am presenting my notes on the difficulties and maturity of Enterprise Architecture, which is critical for enterprises' comprehension of information, application portfolio, and enterprise processes to put business goals at the forefront of considerations.
EA Maturity Is on The Rise!
EA maturity models are typically graded between 1 and 5, reflecting "progress" rather than a destination. IT process integration with Level-4 and Level-5 capabilities is expected in those maturity models.
As vital as EA is to corporations, realizing that EA disciplines cannot be enhanced with the same philosophy that EA was adopted with is essential. This is not about criticizing that approach here; rather, the point is that we require a lot more of that first philosophy or mindset if you like, and not to mention that future success is dependent on steady advancement in EA practice.
In a nutshell you may ask “how one can figure out the maturity level of EA practices by observation?” The answer would be straightforward; the level of technical complexity that EA reduces, the quality and frequency of architectural decisions, or the level of interaction with other IT functions are all indicators of EA success which without a fine holistic view organization simply will suffer and stuck.
EA Maturity: CIO's Role
Nowadays, the CIO is less about being a technologist and more about being a strategist and her respective IT organizations will need to show a high level of harmony with business with the focus on business values.
To suggest that CIOs are business acumen executives is not an exaggeration if their IT unit can present enough business comprehension and all IT decisions are being influenced by business objectives. This refers to helping businesses to grasp business architecture and application portfolio reflective in EA jargon. Consequently, business outcomes pragmatically will be driven by enhancing IT decisions under the influence of enterprise architecture.
Today a CIO must be able to sell the value of IT not just the services, but also IT people and positions and their benefit to the business.
The fact is IT is a global pandemic that the world has chosen to welcome and as a CIO one should not fail to connect business and IT!
EA: How it Relates?
While EA does not have direct control or ownership over all the functions, it has the ability to affect all types of decisions made across the enterprise. As a result, increasing influence and imposing interaction governance will enable IT services to make higher quality decisions which ultimately will lead to business targets becoming achievable. Besides, EA has a direct impact on reviving the focus on business targets which we discussed earlier. (If you're wondering how EA “will” and “should” help business outcomes be achieved, consider BPI, MDM, BPM, and that sort of processes.)
So, as a proposal, if your organization is experiencing issues with the aforementioned sample processes, you urgently want business architecture, and there appear to be chances to improve business in addition to some alignment in application portfolio to be change-aware too.
Integrating diverse points of view is a key issue in EA implementation, but if done correctly, it will demonstrate that EA is not engineering practice and it is more like a strategic mindset that a CIO shall cultivate I believe.
One of the main aims of EA is to encourage collaboration, which translates in the ability to broaden common knowledge of a specific activity, as well as to highlight cost-benefit and present “options”, which ultimately lead to improved designs.
Yet another thing I'd like to emphasize here is that EA isn't always referring to the corporation as a whole. The EA discipline must be adaptable enough to be used to a wide range of scopes, from a single project to a group of organizations within a corporation. As a result, the cost-benefit analysis provided by EA may vary depending on the scope.
Initial EA Implementation Qualities
The original intent of conducting an EA program is frequently to build technology standards as well as a set of processes through a consistent set of artifacts that will be documented and disseminated across. This is happening during early stages of EA adoption which will be benefiting in reducing the design complexity. As a reason, in a CIO shoe, you may wish to select the simplest form of team topology: A "Foundation or Core" team, "Domain" teams, and most likely a "Partnership" team. Those teams, in turn, will be in charge of initial governance (Reference Architecture, Design Patterns, Principles, Policies, Frameworks, and so on), Domain teams will be looking into specific domains (like application, infra, data, etc., or in TOGAF language BDAT), and finally Partner teams will be made up of SMEs to help resolve specialized dimensions of the problem. In various organizations, SMEs are typically members of domain teams that aren't fix players in any case, which is perfectly fine for this level of maturity.
Improved EA Implementation Qualities
Long story short, by implementing early EA qualities, the enterprise has created a collection of self-contained disciplines that can be deployed to the majority of the organizations. I'm referring to SLDC, Service Management, Project and Portfolio Management, and Control Frameworks, among other things.
In this post, the IT position has been portrayed as a driver of attaining business objectives. The proposal is to increase the use of IT processes, but many organizations believe that they are having difficulty take more from existing disciplines, primarily because individual IT processes have reached the point where the marginal output of the processes decreases as the amount of a single factor is incrementally increased. (Diminishing Return is the name given to this phenomenon by economics.)
Probably, the initial implementation of EA in an organization will leave it up to the third level of maturity, which is where the battle emerges and continued improvement in EA maturity is necessary.
As a result, like previously stated, a higher level of engagement with IT processes is suggested, with the quality of the ensuing decision and business outcome serving as a measure of maturity.
Increasing the Effectiveness of EA
You cannot expect playing authority card and forcing EA help organizations to focus on the outcomes and enhance EA effectiveness. It entails blending interaction, influence, and governance to improve decisions.
As a CIO trust that even a broken EA program still helps, synergize with business, include a variety of viewpoints, Utilize Business Optimization and Simplification Planning, concentrate on business results, invest on governance model and you need to be able to respond to some questions like: How well do you grasp application portfolios and business architecture? What is the architecture of your organization’s IT processes? What is the level of interactions between different disciplines? How successfully do IT and EA collaborate with the business?
These types of questions aid in determining a person's clarity of vision regarding the mission at hand regardless of your EA maturity.
Cheers,
Mohammad Malekmakan
Disclaimer:
All opinions and content published in my blog and my social networks are solely my own, not those of my employer(s) and the communities I am contributing in.