Note: This article was originally published on
LinkedIn by the same author.
It is no surprise that the COVID-19 pandemic has brought greater focus on digital transformations for small, medium and large enterprises. However, for a successful transformation of an enterprise from whatever their current state is, it is important to understand the holistic journey from current state to future state via one or more transition states.
This has fueled the importance of a role, called the "Enterprise Architect (EA)" who develops and adopts IT architecture principles that help organizations plan a successful digital transformation journey.
However, often the term "(IT) architecture" is considered a catch-all term for figuring out all sorts of "technical" approaches and methodologies. As a result, Enterprise Architecture also gets dragged into this catch-all definition minimizing the importance of architecture planning process that needs to be done alongside the business planning process.
This article provides a point-of-view of the role an EA plays in digital transformations while also highlighting other types of architecture skillsets that organizations may need to utilize in the overall digital transformation journey.
Plan, Build & Run
Large transformation work need to be addressed in 3 buckets - Plan, Build & Run. While "Build" is the largest portion of investments in any transformation program, it is obvious that organizations are required to safeguard whatever has been built with minimal "Run" budgets. "Build" and "Run" are cyclical in nature. For example, you build, then you maintain (run), then you either build more or something new and then maintain (run) that more or something new. So it is pretty obvious that leaders responsible for large transformations think of Build as the starting point and transition to Run as the end.
It is senior leaders however that need to see things being built (and run) as building blocks of a vision or the journey. This is the Planning function (which is strategic). The "Plan" function needs to be executed by someone who understands business vision and maps the journey to that vision. S/he does that by identifying business capabilities and value chain (not business process), and then developing the strategy as building blocks. The skill required to do this is called "Enterprise Architecture".
Architecture work that is Enterprise Architecture
The role an EA plays in large transformation programs should have started even before the transformation program has begun. Although, during the program, an EA plays a crucial role in the as-is and to-be phases (a.k.a. Design phase in Waterfall or Sprints equivalent of Agile methodology). Some of the tasks that an EA might be required to lead are:
- Developing / enforcing enterprise standards. Examples - application rationalization, instance strategy (not landscape strategy), deployment strategy (think functional / capability deployment), business process integrations, etc.
- Application selection - as a consultant in making sure multiple vendor offerings are compared (options analysis) and influences the buying decision.
- Technology standards. Examples - API strategy, Cloud strategy, Platform selections, Integration tools & methods, etc.
- Provide guidance on managing business data objects. Examples - Master Data strategy, Reporting & Analytics strategy, etc.
- Identifying opportunities for innovation. This has to be done with a rational balance between adopting innovations (in the form of COTS) vs innovating in-house - a.k.a. Build vs Buy. Generally, it makes sense to build when the business capability is niche or competitive.
- Keep an eye on moving target. This I think is a core EA responsibility because organizational targets keep moving. For example, acquisitions occur, large customer onboards (or is lost), , lawsuits get filed, etc., and the organizational focus will change right in the middle of the transformation. That's where EA needs to assess the impacts of these business environments and steer the transformation program.
Architecture work that is Other Architecture
Now, while the above reflects EA role, that's not all the "architecture" work. The EA role is often confused with Solution Architects or Development Architects - especially in organizations where there isn't a central architectural stronghold. This is where EA gets trapped. Therefore, I think it is also important to call out what EA is not and educate leaders on other types of architects. For example, inexperienced associates and leaders think of following as an EA role. Although these are architectural questions, these are "Build" related questions and are to be addressed by Solution Architects or Solution Experts and not an Enterprise Architect.
- Infrastructure selection / design
- Landscape strategy / technical deployment strategy
- Coding standards
- REST vs SOAP comparison
- CouchDB vs MongoDB
- Solution demonstrations
- Cutover planning
- Build to Run transition
- etc.
Conclusion
As stated in the beginning, this article aims to provide better clarity to what is Enterprise Architecture and the role an Enterprise Architect (EA) plays in digital transformation programs. Also, the secondary aim is to paint a view of different kinds of architecture responsibilities in an organization, especially those that fall within the "Build" phase of the transformation program.
However, it must be also acknowledged that depending on the size of the enterprise, it may not be possible to create roles mapping to specific architecture skillsets. In that case, the skillsets must be shared by few architects. However, for architects who share responsibilities towards multiple architecture domains, they must be able to differentiate between an "Enterprise Architecture" responsibility and an all encompassing, "other architecture" responsibilities; and one way to do that is ask yourselves which bucket is the work aligned to - Plan, Build or Run?
Now, this may be just one of the approaches to think of the value and EA brings to digital transformation programs. Are you aware of any other approaches this community can leverage when discussing the value of engaging Enterprise Architects early-on in the enterprise transformation initiatives?
