Technology hype cycles, S-curves and the role technology plays in innovation

In ENTR 810 Emerging Trends, Technology, and Corporate Innovation, we examined several tools that can be used to by EA to evaluate emerging technologies as well as help manage the risk/reward trade-offs that come with technology innovation. Below is a summary of these tools and how they can be applied to the practice of EA (Coughlan, 2018).

The hype cycle and S-curves help to provide context on the technology lifecycle in two primary dimensions: the relative cost or effort (i.e. time & money) of the technology, and its efficacy for solving real-life problems or use cases; however, each model uses slightly different dimensions. The S-curve measures two dimensions: ‘Effort’ on the X-axis (i.e. time & money) and ‘Technical Performance’ on the Y-axis. The S-shaped curve that results describes how at the beginning of a technologies life there is there is a great deal of investment with relatively little performance improvement until some tipping point in which the performance increases dramatically. Finally, at the end of a technologies life, the performance improvements become less distinguishable and then plateaus. Graphically, this curve takes the shape of a flattened “S”, hence the term “S-curve”. As is often the case, a parallel S-curve is developing for the technology that will eventually overtake the obsolete technology. For example, the PC was largely replaced by the laptop, which is now being overtaken by the tablet. These could be modeled by three separate S-curves with each one higher and to the right of the previous.

The hype cycle also provides a picture of the technology lifecycle, but in slightly different dimensions with ‘Time’ on the X-axis, and ‘Expectations’ on the Y-axis. This is referred to as the ‘hype cycle’ because the emphasis is on the expectations of technical performance in the marketplace. It has four primary stages: Innovation Trigger, Trough of Disillusionment, Slope of Enlightenment, and Plateau of Productivity. Whereas the S-curve is more focused on the maturity of the given product in terms of positioning in the marketplace, the hype cycle helps decision makers assess the benefits of a new technology in the context of their specific industry given their tolerance for risk.
Both of these measures help to provide context for a particular technology in terms of the potential risk and reward. From an investor’s perspective the higher the risk the greater the reward, so the investor is keen to select technology investments that are early in the S-curve. For the technology company looking to innovate in the market, they need to understand the technology life-cycle and the implications it has on the valuation and target market. Finally, from a technology management perspective, understanding where a technology is in the hype cycle comes to bear in the decision making and timing around the adoption. Take for instance the introduction of the iPhone, early on the iPhone differentiated itself in some key features (e.g. touchscreen), but failed to provide some features we now consider to be essential (e.g. GPS).

A best practice for Enterprise Architecture (EA) is to approach innovation from a technology management perspective. Part of my job is to manage the roadmap of technology adoption. Understanding where a technology is in the hype cycle comes to bear in the decision making and timing around the adoption and helps to prioritize R&D investment. The key to adding value as an EA is the ability to understand and anticipate what problems the organization is going to have in the next 2-5 years. Like Wayne Gretzky has been quoted as saying, “A great hockey player plays where the puck is going to be” (BrainyQuote, n.d.). By using tools such as the Gartner hype-cycle analysis, we can develop an understanding of what technologies to prioritize for investment (i.e.time & money) so that when the need arises we have a complete/partial solution, that is ready to incorporate into the operating environment.

Coughlan, C. (2018, September 17). ENTR 810 Emerging Trends, Technology, and Corporate Innovation.

Wayne Gretzky Quotes. (n.d.). Retrieved from https://www.brainyquote.com/authors/wayne_gretzky

Why Capability Is the Missing Link in Business/IT Transformation

The business capabilities provide a common language for an organization. As a central focus for communication and collaboration across many business units, business capabilities views offer stakeholders a common understanding of the business gaps that need to addresses. Once a shared understanding of the business is established it can be used for planning and executing business/IT transformation efforts, and help to mitigate some of the resistance encountered when undertaking the development of the Enterprise Architecture.

In Developing Enterprise Architecture via Business Capabilities (Vaessler, 2015), the author outlines the principles that provide business capability modeling such a unique and powerful approach to collaboration and contributing to a shared understanding of the business:

1. Business Capabilities define WHAT a business does, not HOW a business does something.
2. Business Capabilities are nouns, not verbs (e.g. investment management).
3. Business Capabilities are defined in business terms, not technical terms.
4. Business Capabilities are stable, not volatile.
5. Capabilities are not redundant.
6. There can be only one Business Capability Architecture view for a business.
7. Business Capabilities map to but are not the same as, a LOB, business unit, business process, or value stream.
8. Business Capabilities have relationships to IT deployments and future-state IT architecture.
9. Automated capabilities are still business capabilities — not IT capabilities.
10. Capabilities are of most value when incorporated into a larger view of an enterprise’s ecosystem.

One way to apply this approach is to (step 1) use the business capabilities view to build a reference architecture of the target-state or Business Capability Architecture (BCA), and then working backward to identify which capabilities should be prioritized to achieve the goals of the transformation effort and a timeline of roadmap for achieving the target-state (step 2). Finally, if the business capabilities view and the roadmap help define the WHAT and the WHEN, the next step (step 3) is a conceptual or high-level view of the HOW which forms the architectural view of the organization or EA.

In the example provided by the author, to achieve this next step, the architecture team employed TOGAF’s concept of Architecture Building Blocks (See TOGAF 9.1 Section 37.2). Similar to business capabilities, ABBs are solution agnostics, and for that reason are helpful to remain focused on the problems to be solved (i.e. requirements) (Vaessler, 2015):

  • They can represent the fundamental functionality of an area of technology
  • They capture and represent architectural requirements
  • They can interoperate and possess relationships with other ABBs
  • They can map to business capabilities
  • Their higher level of abstraction means that they aren’t required to define or reference any specific technology or IT product(s).
  • They can be further decomposed into individual Solution Building Blocks (SBBs) once more is known

In this final step, a business capability (e.g. Customer Information Management) could be linked to the ABBs that comprise the architectural requirements and a blueprint of the future. In my experience the process described above is often skipped by going directly to a solution without a fundamental understanding of requirements and their implication for the success of the project; however, those EA groups that can do this successfully will win the support of stakeholders and contribute far more to the business outcomes with which they are concerned.

How to Embed BA in the Organization (Then and Now)

In How to Embed BA in the Organization (2013), Miers and Barnett argue that one scenario in which business architecture provides a great deal of value is in customer experience (CX) driven transformation initiatives. These transformation efforts, are focused on reinventing the experience delivered (and hopefully value) to customers. In doing so, “teams design customer, product, and service life cycles through customer journey maps, with input from the voice of the customer (VoC) programs. Leveraged capabilities also provide the link through to the processes that affect the customer and the IT systems that underpin them” (Miers & Barnett, 2013). The key takeaways from that article include ring true today, but a trend related to how many firms are now organizing these transformation efforts around continuous planning and delivery approaches has provided a clear opportunity embed business architecture practices directly into the role of the ‘Product Manager”.

In To Successfully Transform IT, CIOs Need Enterprise Architects (2018), Barnett (again) discusses the role that business architecture has on the success of digital transformation efforts.

Strategic decisions are enterprise-wide, not affecting just product or technology. Many firms have well-established and mature product management capabilities within business and technology management. However, business product managers tend to act as CEOs of their product lines, defining their own product strategy, which can result in misalignment of the firm’s business strategy. Technology product managers focus on an individual technology rather than business outcomes, which can result in a well-defined technology product strategy but a lack of business value. EAs have started to productize architectural elements, such as value streams, customer journeys, and life cycles, to align business products and technology products to business strategy. EAs then define strategies for each of these architectural products.

Aside from a few weeks, Barnett’s key takeaways from 2013 have stood the test of time:

Business architecture addresses multiple business challenges.
Business architecture methods, tools, and techniques help all sorts of organizations address multiple business challenges; from cost-effectiveness to customer centricity and the identification of operational synergies.

Stakeholder’s needs drive successful business architecture programs.
Business architecture efforts only make sense in the context of the organization’s needs. The first step is to identify those needs and then design your BA offering to deliver the desired outcome. Take time to make those services consumable.

The Business architecture Toolset Is evolving. As more and more organizations undertake business architecture initiatives, the techniques and methods will continue to evolve. Plan for this evolution by assessing your initial needs and then test the efficacy of your BA artifacts, while remaining open to new approaches. Think of it as a clinical trial for each technique.

References:

Barnett, G. (2018, May 4). To Successfully Transform IT, CIOs Need Enterprise Architects. Retrieved from https://www.forrester.com/report/To Successfully Transform IT CIOs Need Enterprise Architects/-/E-RES143194

Miers, D. & Barnett, G. (2013, June 12). How to Embed BA in the Organization. Retrieved from https://www.forrester.com

The Anatomy of An Operating Model

Business Operating models are increasingly valuable to business leaders, but enterprise architects struggle with creating this core business architecture deliverable. The central value is that these models “move the architectural views from the conceptual “what” and “why” of an organization to a lower granularity of “where,” “how,” and with “whom” it operates” (Barnett, 2013). However, the central issue is that these models lack a standard methodology for their creation. An operating model definition is comprised of five basic elements: services, capabilities, organization, governance, and leadership. Barnett describes these as:

  • Services are a vehicle for providing value to customers.
  • Capabilities enable the execution of the mission.
  • Organization model provides the effective delivery of the value proposition.
  • Governance ensures objectivity and accountability for decision-making.
  • Leadership provides direction for and communicates the mission and vision.

While the business model provides an understanding of the organization’s mission and vision (i.e. why), and the capability map provides an understanding of what the organization needs in order to fulfill that mission and vision (i.e. what), the operating model anchors the business architecture with a view of the organization’s day-to-day operations (i.e. where, how, and whom). The challenge of creating an effective representation of an organizations operating model lies in first understanding each of these questions. Barnett suggests this approach:

  1. Gain clarity on the firm’s purpose. Discuss purpose at various levels. EAs can help stakeholders articulate this in the form of a business model. Ensure that all parties are on the same page and using consistent language.
  2. Understand and map key, enabling, and supporting business capabilities. Collaborate with key subject matter experts to understand what is needed to realize the form’s purpose. Align these capabilities to the value propositions and how they are related.
  3. Configure capabilities for each value proposition they deliver. These should be independent of who will be responsible for delivery.
  4. Collaboratively build the organization structure. Work with key decision-makers to optimize the capabilities.
  5. Facilitate the management and governance discussion. Once the model is built, figure out how to manage it. It is a complex so don’t underestimate this part. Ea should facilitate discussions to add these elements to the operating model.
  6. Communicate to all stakeholders. Once you figure all this out make sure to tell everyone, and make sure key stakeholders understand the operating model as well as their roles, and responsibilities.

 

References:

Barnett, G. (2013, July 16). The Anatomy Of An Operating Model. Retrieved from https://www.forrester.com/report/The Anatomy Of An Operating Model/-/E-RES99601

Making Technology Stacks Work

“The only way that has ever been discovered to have a lot of people cooperate together voluntarily is through the free market. And that’s why it’s so essential to preserving individual freedom.“ -Milton Friedman

In Making Technology Stacks Work (James, 2006), the author addresses how enterprise architects often report that the technology standards they put in place are ignored, often relegating the architecture viewpoints to focus only on the technology architecture. The article provides some best practices to bridging this business-technology divide and helping to communicate the value-proportion to business stakeholders. Some of these best practices include: drawing an ’architecture scare diagram’, opportunistically selecting projects, make friends in the business, including key stakeholders in the development of technical standards, proactively working with projects, make technical standards easy for projects to find and use. All of these are fine, practical examples of how to work collaboratively with EA stakeholders. However, business people don’t want standards, they want solutions, and author Hussein Badakhchani suggests, perhaps the market is a better mechanism for achieving Business-IT alignment.

But first, a problem well understood is a problem half solved. The advice provided by James makes sense, but the problem is a matter of goals. EA programs will continue to ignored and relegated to IT only as long as they are trying to control rather than collaborate. “The reason that this occurs is a matter of perspective. Projects (and the people working on them) mostly have tunnel vision — and rightly so. They are focused on delivering on budget, on schedule, and with minimal risk. Because of this, it should not be a surprise that projects resist — and even resent — these design constraints. To support their position of ignoring architecture standards, project managers can usually demonstrate tangible business benefits emanating from their proposed design. On the other hand, architects struggle to justify their position. At best, they claim IT cost reductions, but these are mostly trumped by the project’s arguments” (James, 2006). Enterprise architects who focus on business outcomes will get the attention of the business.

In Applying KnowIT: Software Defined Everything, Everything as a Service and the Market, offers a completely different way of looking at standards that draw from what he calls the “KnowIT” principles, that is, “NoDev”, “NoOps”, “NoIT”. Badakhchani argues that these principles “can inform the decisions that are made realize the outcomes we desire in order to meet and exceed the expectations of our stakeholders when considering the ‘why’, ‘what’ and ‘how’ of delivering Everything as a Service (XaaS), [and] that a marketplace of services should be our ultimate aim in endeavoring to generate value for the enterprise.” (Badakhchani, 2015). The ‘why’ is fairly straightforward, that is, he makes the case for the benefits of the XaaS, which have been widely touted. The ‘how” is a bit more interesting.

Badakhchani continues that after a standard set of IT services should comprise the foundation of the XaaS platform, that is, Logging as a Service (LaaS), Monitoring as a Service (MaaS), Security as a Service (SECaaS), and Regulation and Compliance as a Service (RACaaS). However, the interesting part is beyond providing for those basic services should be, IT should focus on the efficiency of the market. “As IT decision makers we have it in our power to build platforms upon which application teams can deploy their services, whatever they may be. We can’t and shouldn’t try to imagine what they will deploy nor which services will be demanded by their customers and which ones will fail. Beyond providing a range of fundamental services that maximize the number market participants (adoption of our platform) and the efficiency and security of their operations we would do well to let the market decide what is innovative and successful while we focus on enhancing the market itself” (Badakhchani, 2015).

References:

Badakhchani, H. (2015, September 28). Applying KnowIT: Software Defined Everything, Everything as a Service and the Market. Retrieved from https://www.linkedin.com/pulse/applying-knowit-software-defined-everything-service-badakhchani/?trk=mp-author-card

James, G. (2006, February 14). Making Technology Standards Work. Retrieved from Gartner database https://www.gartner.com/document/code/137199?ref=grbody&refval=911513

Enterprise Information Architecture Strategies for Enterprise Information-Sharing

As the key challenges and key trends show, information sharing is a broad concept that impacts all levels of the organization. According to Gartner (2008), the key topics that support the information-sharing age are:

  • Overcoming silos include case studies and strategies for business leaders and technical strategies for overcoming data barriers.
  • Improving integration includes strategies and techniques to improve data integration, the role of canonical models to improve interoperability, the emergence of data service platforms for cloud computing, and considerations on information security in the Digital Age.

At the insurance company I work, new data integration capabilities are central to enterprise information architecture (EIA) and there are two trends key trends influencing the strategy: the adoption of cloud technologies and the introduction of a SaaS-based policy administration system (PAS) that will exist in parallel with the legacy mainframe PAS, and (2) the desire to support underwriting with self-service analytics for data mining and discovery. These new capabilities include:

  • Integration Platform-as-a-Service (Mulesoft) used for real-time integration with cloud-based systems.
  • Logical Data Warehouses (LDW) which supports the data sharing and advanced analytics strategies.

The Mulesoft iPaaS was adopted after realizing that the existing enterprise service bus (ESB) was not sufficient to integrate with SaaS provider(s). This also came with a shift from an enterprise-centric mindset to the broader ecosystem of service providers.

The LDW is a pattern that relies on data federation and virtualization, rather than the traditional enterprise data warehouse (EDW) pattern that typically involves a centralized repository. Used in combination with real-time replication tools to feed cloud-based data sources into a group of data hubs that are conceptually aligned to the core enterprise data domains, which data analysts can access with self-service data analytics tools. The data is replicated as-is, so to increase the likelihood that users will be able to “catch a fish” from the “data lake”, metadata is provided to help interpret the data, and semantic data is provided to join ‘like’ data from the legacy and new policy systems. Furthermore, in the event more formal data integration is required, having the data staged helps speed up delivery of downstream reporting needs.

References:

Gartner Research Brief. 2008. Gartner Clarifies the Definition of the Term ‘Enterprise Architecture.’

Newman, D. & Gall, Nicholas. (2009, December 15). Architecting for Participation: How Information-Sharing Environments Overcome Information Silos. Retrieved from https://www.gartner.com/document/1256213.

Intelligent Business Process Management (iBPM) Tools are Key to Agile Operational Information

In Ten Steps to Build an Agile Information Architecture (Gartner, 2007), the authors state that “Service-oriented architecture (SOA) brings new challenges to the architecture and management of information. Some companies think that SOA will hide and resolve all their data issues; this belief will prove fatal to many SOA projects. SOA increases the importance of focusing on information management issues”.

In order to better manage this complexity, the best practice (Step 10) is to look both at the business process and the data that supports it. Tying the business process, roles, and information together provides a business context and helps to focus on the goals or outcomes of the process, allowing for better business services and information architectures.

The central issue is that most legacy business applications are siloed in terms of the ability to share information (and capabilities). If a business process or workflow spans multiple departments, information sources, and applications, then the users are often left to manage those processes with post-it notes, email, or custom exception reports used to identify, track and resolve issues that require manual workarounds.

On the other hand, Services Oriented Architecture (SOA) solutions, that is the services themselves, are transactional in nature or CRUD-based (i.e. Create, Read, Update, Delete). This is design pattern is great when, for example, the application is required to support multiple UX (e.g. web, mobile, etc.), or using service wrappers to share information from legacy applications. Likewise, when the business process or workflow spans multiple departments, information sources, and applications, these transactional systems fail to address the business context and specific goal, nor can they address the end-to-end enterprise value streams.

The good news is that these issues represent a great deal of opportunity, in terms of business transformation, in the form of business process optimization and automation. “In most organizations, more than half of all business processes are human-to-human, without the involvement of built or purchased applications. Therefore, in terms of business process improvement, this category of processes makes the most sense to tackle first. IT can assist business users by installing business process management (BPM) suites to help redesign these processes and make them more agile and effective” (Gartner, 2007).

In Magic Quadrant for Intelligent Business Process Management Suites, Gartner defines an intelligent business process management suite (iBPMS) as an integrated set of technologies that coordinate people, machines and things. It emphasizes:
* Support for real-time human collaboration, including integration with social media, mobile and cloud access to processes
* Advanced analytics, real-time activity monitoring and decision management for intelligent coordination and management of the interactions of process participants.

These iBPM systems are also combining BMP with AI and automation in a low-code development to put more power in the hands of the business users or citizen coders which is intended to improve stakeholder engagement and minimize resistance while support agility and faster time-to-market for digital transformation initiatives that seek to streamline processes across the business.

References:

Dunie, Rob, et al. ( 2017, October 24). Magic Quadrant for Intelligent Business Process Management Suites. www.gartner.com/doc/3410738/magic-quadrant-intelligent-business-process.

How Cloud Technologies are Busting the Technology Stack Silos

Organizational silos are a root cause of inefficiencies, lack of flexibility and high costs, and this is especially the case for services-based industries that are highly dependent on business processes that require collaboration across multiple business units (Grainger, 2018); however, there is also benefit from busting the silos of people and technology that have formed around the technology stack. In this post, I will discuss how some emerging technologies are promising to bust the silos that exist between organizational units, both horizontally (between busines units) and vertically, between the technology stack.
Technologies such as General Automation Platforms (GAP)  or are emerging to help manage the ‘lines’ between organizational units and the supporting applications. A General Automation Platform (GAP) or Robotic Process Automation (RPA) is a category of software which automates processes that can span multiple applications across an organization. These platforms emphasize the word “automation” because they are not focused on merely the challenges of integrating. In fact, the standardization of APIs has made the integration part of automation much more straightforward than in years past (Ortiz, 2018). Although it is increasingly common to see applications or application suites packaged with workflow capabilites, thes are typically intended to be utilized within the application or suite. Other achronims in this technology domain would include Business Process Managment (BPM) and Workflow Managment Systems (WMS).
These platforms offer a wide range of capabilities but some comon features would include: connecting API enabled services, visual workflow builders, logical operators (e.g. if this then that or ‘iftt’), event triggers, reporting dashboards, data transformation, data storage, processing scalability, alerting/notificaiton, collaboration/imbedded communication tools, and often security/compliance features to provide tracability to  monitored transaction types.
One of the most important features of these platforms is that they often do not require coding to configure or manage. This “low code” capability is targeted towards business users or ‘citizen coders’ to quickly depoy new solutions. This capability is a great example of busting the silos of people and technology that have developed around the technology stack. For example, to develop the most basic web application could require a UX designer, web developer, database administrator, application server administrator, and a network/infrastructure engineer – not to mention the project manager, testers, business analysts, and other supporting roles. However, as cloud technolgies take over each level of the stack, these either cease to exist or they are replaced by roles that combine the previous functions, like cloud architects.
As I had written last week, the introduction or adoption of cloud technologies has caused these layers to collapse on themselves an is resulting in the elimination middleware and a shift from prevailing enterprise software and integration design patterns (Hawes, 2012).  There are implications for the role of the enterprise architect as well.

 

Sources:

Grainger, R., & IDG Contributor Network. (2018, January 04). 3 steps to building a services-centric tech stack. Retrieved from https://www.cio.com/article/3245805/it-strategy/3-steps-to-building-a-services-centric-tech-stack.html

Hawes, L. (2012, March 15). Enterprise Software Architecture: A Network of Services, Not a Layered Stack. Retrieved from https://www.forbes.com/sites/larryhawes/2012/03/14/enterprise-software-architecture-a-network-of-services-not-a-layered-stack/

Ortiz, A. (n.d.). Save Time Building Integrations. Retrieved from https://tray.io/lp/guide/beginners-guide-to-general-automation-platforms/download

The Solution Architect as the ‘Architect of Change’

Last week I talked about how digital disruption and the influence of cloud technologies fundamentally shifting how we think and communicate about the structure of the enterprise architecture stack. This week I would like to expand that conversation to discuss what impact this has had on the structure of the EA team. In Application Architecture Overview (Parts I – III), analysts Mike Blechar and Bruce Robertson lay out some of the key differences in the roles of Enterprise Architect, Solution Architect and Application Architect. The central differences seemed to parallel the common architecture viewpoints, that is, the enterprise architect role tends to focus on more conceptual deliverables, whereas the solution architect role focuses more on logical deliverables (in the context of the particular project), and the application architect focuses on the implementation.
My company employees a similar structure to the architecture team. At first scan, this could seem to be overly complex and bureaucratic, and that is the risk; however, the value of this structure becomes evident when you view this as not a hierarchy but of a network of contributors each adding their perspective to the overall enterprise architecture. Most notably, it is through the solution architect that the enterprise solution architecture (i.e. vision, standards, and principles) are applied to a specific project/problem context. At this more detailed or logical level of design, the SA’s role “includes designing and reusing software service and interfaces, which improves developer productivity and application agility, quality and consistency” (Blechar & Robertson, 2010), but the real value that the Solution Architect provides is ‘Silo Busting’. Furthermore, leveraging the SA role in this way seeds the enterprise mindset throughout the organization promotes the vision, and allows adaptation of new standards and technologies to quickly scale while allowing ownership of the ‘boxes’ to remain with the application owners. 
In a previous post, I discussed what it means to be an agile enterprise. Michelle Parsons (2018) argues that “agile is not the answer to all of your company’s problems. Silo busting is”. Her line of thinking is that communication across the organization or silo busting is the key ingredient to organizational agility and getting things done. Solution architects focus on the lines between the boxes – both organizational and system boxes. It is the solution architect’s role to foster collaboration between business silos, and more and more this is manifesting itself in the technologies themselves. Technologies such as General Automation Platforms (GAP)  or are emerging to help manage the ‘lines’ between organizational units and the supporting applications. A General Automation Platform (GAP) or Robotic Process Automation (RPA) is a category of software which automates processes that can span multiple applications across an organization. These platforms emphasize the word “automation” because they are not focused on merely the challenges of integrating. In fact, the standardization of APIs has made the integration part of automation much more straightforward than in years past (Ortiz, n.d.). These platforms also tend to focus and speak in terms of business processes and incorporate “low code” capabilities that allow non-programmers to implement solutions. So the role of the Solution Architect is to architect business solutions that span multiple business domains, and while they help ensure the APIs support those solutions, their role has been elevated to what Bloomberg calls the ‘architects of change’ and the realization of business transformation and agility.
Sources:
Blechar, M., & Robertson, B. (2010, December 08). Application Architecture Overview, Part 1: General Context and Scope. Retrieved from https://www.gartner.com/doc/1487814/application-architecture-overview-general-context
Ortiz, A. (n.d.). Save Time Building Integrations. Retrieved from https://tray.io/lp/guide/beginners-guide-to-general-automation-platforms/download
Parsons, M. (2018, August 8). Forget about Agile vs. Waterfall, Its About Silo Busting … Retrieved from https://www.linkedin.com/pulse/forget-agile-vs-waterfall-its-silo-busting-michelle-parsons/
Robotic process automation. (2018, August 13). Retrieved from https://en.wikipedia.org/wiki/Robotic_process_automation

How can we, as Enterprise Architects, be the change we seek?

In Change as Core Competency: Transforming the Role of the EA, Jason Bloomberg (2016) alerts that EA must transform itself into ‘agile architecture’ in order to drive digital transformation. His view, like Hawes (2012), is that of the enterprise as a complex adaptive system with emergent properties, that is properties that emerge from the interaction of the different components that comprise the system itself. Agility, efficiency, effectiveness, and resiliency are all examples of emergent properties, but Bloomberg sees agility as critical property and change-ability as a core-competency for organizations to develop; however, unlike Kotter’s archetype of the change agent where “a single individual or small group of individuals are responsible for driving change in a previously static organization” (Bloomberg, 2016), the goal should be focused on helping the organization to better respond and adapt to the forces change. The implication for EA is that we must dispel the myth of the future state, and instead focus on making the current state better. That enterprise architects must become ‘architects of change’, by focusing on what is required to enable or realize it or to better leverage change for competitive advantage.

So what does Bloomberg mean by ‘agile architecture’ or ‘architects of change’? In a previous article, Is Enterprise Architecture Completely Broken? (2012), he states that “the writing is on the wall. For all the Miltons in the role of Enterprise Architect, applying frameworks and creating artifacts and generating documentation, the business value they provide is questionable at best”. He continues, “those EAs who truly embrace change – who work directly with business stakeholders to move their organizations to an increasingly agile state of continuous business transformation – will more likely find themselves adding real value to their enterprises”. Sounds great, but specifically how can EA add value? In part, I think the answer lies in the second wave of cloud adoption that has already started to shift the way of thinking and to bring to market new tools to help manage the tangled web of technology that resulted from the first wave (Grainger, 2018). I will save that discussion for later. First I would like to address this question: How EA can be agile?

“In one physical model of the universe, the shortest distance between to points is a straight line, in the opposite direction.” – Ty Webb (Caddyshack)

Somewhat ironically, Michelle Parsons (2018) argues that “agile is not the answer to all of your company’s problems. Silo busting is.” According to Parsons, efforts to implement agile in organizations are great, but doing agile does not mean the company as a whole is (capital ‘A’) Agile. Nor does it mean the company is effectively delivering business value to customers. Her line of thinking is this: “Agile vs. waterfall isn’t the issue, it’s communication across the organization. Silo busting is the key ingredient to successfully getting stuff done”.

Parsons makes several recommendations on how to approach silo busting, but I want to focus on one, in particular, that is having a single, prioritized enterprise backlog. “Why is this important?”, she asks, because “If you don’t establish a priority, people will make one up”. The perhaps more subtle point here is that the enterprise backlog is itself valuable, but it is the act of creating the backlog that provides the real value, by forcing the communication and collaboration between the business, finance, IT, program management, and the other verticals that must all come to consensus on the direction an priorities of the organization. (Note: This also has implications for how EA can better serve agile development practices.) In this example, vertical silos are the root cause of inefficiencies, lack of flexibility and high costs, and this is especially the case for services-based industries that are highly dependent on business processes that require collaboration across multiple business units (Richards, 2017); however, there is also benefit from busting the silos of people and technology that have formed around the technology stack.  In Part III, I discuss how cloud technologies like micro-services are influencing the technology stack. To be continued.

Sources:

Bloomberg, J. (2016, June 16). Change As Core Competency: Transforming The Role Of The Enterprise Architect. Retrieved from https://www.forbes.com/sites/jasonbloomberg/2016/06/16/change-as-core-competency-transforming-the-role-of-the-enterprise-architect/

Hawes, L. (2012, March 15). Enterprise Software Architecture: A Network of Services, Not a Layered Stack. Retrieved from https://www.forbes.com/sites/larryhawes/2012/03/14/enterprise-software-architecture-a-network-of-services-not-a-layered-stack/

Bloomberg, J. (2014, July 11). Is Enterprise Architecture Completely Broken? Retrieved from https://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/

Grainger, R., & IDG Contributor Network. (2018, January 04). 3 steps to building a services-centric tech stack. Retrieved from https://www.cio.com/article/3245805/it-strategy/3-steps-to-building-a-services-centric-tech-stack.html

Parsons, M. (2018, August 8). Forget about Agile vs. Waterfall, Its About Silo Busting … Retrieved from https://www.linkedin.com/pulse/forget-agile-vs-waterfall-its-silo-busting-michelle-parsons/