Reframing the Role of Enterprise Architecture
As the debate about the value and definition of Enterprise Architecture (EA) continues, in 2013, Comerica decided to re-explore the topic. Several years ago, the bank started an EA practice that eventually evolved to what we currently define as Solution Architecture, which has a more focused and tactical view and is primarily engaged in supporting the architecture and design needs of specific initiatives and projects.
What prompted our IT leadership to re-visit the topic of enterprise architecture was the realization that rapidly evolving and disruptive forces are converging, in a manner that requires not only a new way of looking at how we develop technology strategies, but also how we architect and realize these strategies.
The disruptive forces that are shaping our industry and are influencing our choices include:
• The rapid acceleration of digital transformation that is occurring in the industry in general, and finance and banking in particular.
• The creation of new business designs and models built by blurring the digital and physical worlds via an unprecedented convergence of people, business and things.
• The continuous evolution and pervasive nature of regulation and compliance.
• The need to effectively deal with the changing landscape of cyber security.
• The need to truly balance the investment needs of running the business, growing shareholder value and transforming the way we engage with our customers.
• The transition to ‘always on’ brought on by the ubiquity of mobile smart devices; and entrance of non-traditional banking institutions in the financial services markets (Apple, Google, PayPal).
Based on these realities, along with our earlier experience in enterprise architecture–which we refer to that as EA 1.0–we are evolving and reframing our definition and usage of enterprise architecture at the bank.
As a starting point, we have reached internal consensus about what EA should not be about, and that is, the practice of documenting everything about the enterprise, strict adherence to frameworks, and the indiscriminate enforcement of standards.
Instead, we want enterprise architecture to be about facilitating business change and becoming the foundation for executing our business strategy. We want it to enable business strategy and to decrease the cost and time to market of technology solutions. We want it to support our business in the foundational decisions and designs about architecture. Lastly, we want it to be forward looking, becoming that vanguard technology team that facilitates shaping the business strategy. In essence, we want it to see the bank as a living organism–as a complex system–that is constantly evolving, changing and adapting to the ever changing business ecosystem.
Our vision for the future with EA is to get to a level at which we can co-create business technology strategies with our clients and business strategies with technology components.
The approach we are taking in building the EA practice relies on the following basic principles:
• Start small. Avoid requiring huge investments that might one day deliver value.
• Build incremental successes in critical business areas rapidly.
• Identify top of mind pain points and opportunities for the
business that will benefit from the practice of EA.
• Prove the EA value by doing; by solving business problems.
• Adapt methodologies and frameworks specifically to the bank’s
• Develop documents that are easily understood by our business and are used by the business in their own decisions.
• Create demand for EA services-we want the business to ask for help from enterprise architecture.
• Work in a way that the business becomes the evangelist for EA services.
• Significantly support senior IT and business leaders in decision making and finally,
• Become integral, ongoing partners and trusted advisors to our business.
To build and enable our enterprise architecture practices to achieve these goals, we are positioning the EA function to work directly with our business clients and focus on solving business problems by taking a data-driven approach to business transformation.
As a starting point, we have identified areas that will benefit immediately from an enterprise perspective. These include application rationalization as a means to cost reduction, simplification of technology and identification of untapped capabilities. Technology lifecycle management also is an area that benefits, in terms of reducing technology cost and risk. There also is a benefit in the optimization of our payments and enterprise risk processes, ensuring resilience and flexibility of technology involved. The introductions of business capability models help identify a common language and frame of reference to engage with business leaders. The development of continuously available IT services, such as data centers, applications, etc., also benefits from an enterprise perspective.
Having an enterprise perspective also benefits in the development and implementation of a “fit for purpose” innovation-enabling environment to allow us to handle the opportunity that digital disruption introduce. Finally, another benefit to having an enterprise perspective is in the development of reusable patterns–encapsulating our architectural vision and strategy–which our solution, design and engineering teams will leverage in programs and projects.
Like any journey to a new and mostly unexplored area, we have expected and are facing challenges. At the forefront of these challenges is transitioning from strategies that are usually built mostly around business units to a more enterprise focused orientation. Other challenges include developing a more disciplined and metrics-based method of defining strategy and tactics, and developing an effective operating model for EA that will bring together organizationally dispersed architecture functions.
Some of the ways we have found that helped us overcome these challenges include having senior business and IT leadership visibility and support, being positioned organizationally at the appropriate level, and raising the level of communication and understanding of what enterprise architecture is all about. It also includes having consistency in approach and being facts-based, articulating what results are we experiencing. We also know that value cases speak volumes (efficiencies both in dollars and intangibles), and that we should treat enterprise architecture as a business capability and process. Finally, we overcome challenges by creating demand for EA services from business units, by aligning and showing how EA helps them achieve business goals.
As we restart our journey with Enterprise Architecture version 2.0, and having gone through the growing pains and challenges of one “type” of architecture practice, we are extremely confident that this time around we will take the promise and expectations of the discipline to a place that will establish it as a critical and indispensable business and technology function within the bank. Some extremely promising signs that we see include the willingness of our business clients to work closely with our EA team, and in some cases willing to fund staffing positions.
Our business is seeking to understand and implement digital transformations across the organization. Technology enabled business transformation requires a more agile approach to architecture. We believe that the path we are taking with re-establishing Enterprise Architecture at the bank will create an agile architecture foundation in order to drive digital transformation effectively in today’s increasingly connected and digital world.