Over the next few weeks I’ll be working through the MOOC titled, “UX Design Fundamentals.” It is the second course in the UI/UX Design Specialization, following “Visual Elements of User Interface Design.”
The course is advertised as a hands-on course which examines “how content is organized and structured to create an experience for a user, and what role the designer plays in creating and shaping a user’s experience.” It highlights a condensed process that acts as a roadmap for developing robust UI/UX design. This condensed process looks to be as follows:
The ultimate goal is to produce a digital prototype for a multi-screen app of one’s own invention.
UI/UX: What’s the difference?
The specialization concerns both User Interface (UI) and User Experience (UX). The first course in the series, focused on the UI aspect of UI/UX, the interface design. This second course focuses on the UX part, the experience. And, an initial challenge of this separation, at least to me, is that it can be unclear as to the distinction between UI and UX.
According to the initial course video lectures, UI refers to how the digital experience looks; UX as to what that experience feels like. Specifically, UI is concentrated on form (shape), aesthetics, color, typography and organization - peraps the more traditional graphic design principles. With this in mind, UI "ends up being a more about the surface" of a product or service.
UX represents the more intangible aspects of interface design such as how things feel or what emotions are evoked. From this lens, UX relates more to a user's engagement or the level of activity of interaction.
Thus, UI is perhaps more tangible whereas UX leans to be more propositional.
The course indicates that the rationale for this separation is to explore the UI and UX disciplines in more detail albeit they do intrinsically inform each other and both are indeed key aspects of design.
For those interested in learning more, the course URL is listed below.
Today’s business climate is defined by constant change and increasing competitive pressures. As companies strive to maximize growth and profit margins, they face more demanding customers, new regulations, globalization, digitization, and the disruptive effects of the newest advancements in technology. There is relentless pressure to streamline processes, sustain profitability, drive inventory, create innovative sales and marketing programs, and share information in real-time. All of these critical factors are changing the marketplace significantly - introducing new challenges and generating new business requirements.
In this ever-changing digital world, new businesses emerge, while old ones either adapt or disappear; they succeed on their ability to embrace and effectively unleash the power of innovation. Rather than just supporting traditional methods, digital transformation inherently enables that innovation. A key responsibility of any leadership team is to ensure that the business not only survives, but also thrives under these new market conditions.
Next-Generation Enterprise Architecture (NEXEA) isn’t just about business, digitization, or new technologies; rather, it takes the most important elements of each and fits them together to build a more powerful engine. Utilizing a business-oriented approach, NEXEA is the alignment of industry strategies and models with emerging technology enablers. That’s the beginning of digital transformation.
LiquidHub’s Next-Generation Enterprise Architecture Playbook - a recently published book (Summer 2013) - presents digital transformation concepts - and is geared for business leaders, both business and IT, who want to help their organizations build more effective, #digitally-oriented solutions. We hope business executives use the playbook to drive strategic innovation that improves customer interaction, advances technology integration, promotes cost efficiency, and supports growth.
To request a harbcopy, please email: firstname.lastname@example.org
1. The original Zachman framework, The Information Systems Architecture - A Framework, was created in which year?
2. The 2011 edition of the Zachman Framework is now defined as which of the following?
a. An Enterprise Ontology
b. An Business Architecture
c. A Business-Oriented Architecture
d. A Business-Oriented Framework
3. Which of the following best describes the benefit of EA artifacts?
a. EA artifacts help business stakeholders better understand the components of a business
b. EA artifacts help business stakeholders communicate business strategy and design
c. EA artifacts help business stakeholders design, manage and implement business change
d. All of the above
4. Which of the following is NOT a business transformation competence according to LiquidHub’s business transformation roadmap?
a. Governance and Program Management
b. Solution Design
c. Next Generation Architecture
d. Continuous Innovation
5. Which of the following statements best encompass LiquidHub’s capabilities?
a. LiquidHub is expert in business strategy
b. LiquidHub is expert in IT Enterprise Architecture
c. LiquidHub is expert in Digital Business Transformation
d. LiquidHub is expert in IT Staffing
6. Which of the following statements best describes LiquidHub’s definition of Next Generation Architecture (NGA)?
a. NGA is the contemporary view of EA and meant to capture the significant shifts in digital business models and enabling technologies
b. NGA is a summary, informal view of an enterprise used at the IT project level
c. NGA is a database of project implementation artifacts used to accelerate a project’s time to implementation
d. None of the above
7. Which of the following statements best describes LiquidHub’s definition of Business-Oriented Architecture (BOA)?
a. BOA is an outcome and target state descriptor of implementing NGA
b. BOA is the LH applied industry/vertical domain expertise on top of our EA fundamentals
c. BOA is used to help signify that a next generation architecture should be business oriented
d. All of the above
8. Which one of the following statements best describes LiquidHub’s standard architecture “domains” or “layers?”
a. Business Architecture, Application Architecture, Information Architecture, Infrastructure Architecture and Governance
b. Business Architecture, Application Architecture, Information Architecture, Technology Architecture and Governance
c. Business Architecture, Application Architecture, Data Architecture, Technology Architecture and Governance
d. Business Services Architecture, Application Architecture, Data Architecture, Technology Architecture and Governance
9. Which one of the following statements best describes LiquidHub’s NGA Toolkit?
a. The NGA Toolkit is a tool for developing Technology Architecture only
b. The NGA Toolkit is a method for IT Governance
c. The NGA Toolkit is a reference model for IT Architectures.
d. The NGA Toolkit consists of a framework, method and supporting tools to facilitate digital transformation
10. How many key tools does the LiquidHub NGA Toolkit contain?
11. Which one of the following is NOT a key NGA “Tool?”
a. Meta Models
b. Reference Models
c. Solution Architecture Map
12. Which of the following best describes LiquidHub’s NGA Framework?
a. The LiquidHub NGA Framework is a comprehensive collection of models (e.g., blueprints, lists, financial statements) that are used to describe an enterprise’s design; often arranged in a matrix format
b. The LiquidHub NGA Framework consists of qualitative statements of intent that should be met by the architecture, along with a supporting rationale, measure of importance and business implications
c. The LiquidHub NGA Framework consists of a process or methodology to populate the framework with current and future state information
d. None of the above
13. What is LiquidHub’s NEXAR?
a. LiquidHub’s enterprise architecture framework
b. LiquidHub’s enterprise architecture roadmap which is presented as the integration of enterprise architecture deliverables and methodology
c. LiquidHub’s business-oriented architecture
d. LiquidHub’s solution architecture and method
14. Which of the following best describes LiquidHub’s “layered enterprise” concept?
a. Multi-enterprise Value Chain, Enterprise, Division, LOB, Solutions
b. Multi-enterprise Value Chain, LOB, Solutions, Components, Elements
c. Multi-enterprise Value Chain, Enterprise, LOB, Solutions, Components
d. None of the above
15. Which one of the following elements is NOT consistent with LiquidHub’s EA Reference Model?
a. Enterprise Financial Statements
b. Enterprise Portfolio Management
c. Digital Asset Management
d. File and Print Services
16. What key factors influence an organization’s ability to manage a successful EA practice?
a. Organizational Structure
b. Organizational Culture
c. The EA group’s interaction with implementation
d. All of the above
17. Which of the following statements best describes LiquidHub’s definition of Business Architecture?
a. Business Architecture is the high-level methods for modeling, measuring and monitoring an organization’s business processes.
b. Business Architecture is the business strategy, governance, organization and key business process information as well as the interaction between these concepts
c. Business Architecture defines the mix of corporate, line of business and function strategies of an modern enterprise
d. None of the above
18. In LiquidHub’s terminology, there is no difference between a business capability and a business process?
19. Which of the following statements best describes LiquidHub’s definition of the 5 key Business Architecture views or models?
a. Business Capability, Business Process, Organization, Product/Service, Use Cases
b. Business Capability, Business Process, Organization, Product/Service, Channel
c. Portfolio, Business Process, Organization, Product/Service, Channel
d. None of the above
20. Which of the following statements best describes LiquidHub’s definition of Application Architecture?
a. An Application Architecture is: a description of the major logical groupings of capabilities that manage the data objects necessary to process the data and support the business
b. An Application Architecture is: the design & management techniques for transitioning from a set of business process models to a portfolio of business services as well as the management and coordination of the services portfolio
c. An Application Architecture is: the set of application meta models, data elements and infrastructure components that enable the business’ enterprise logic
d. None of the above
21. Which of the following statements best describes LiquidHub’s definition of an Enterprise Architecture Metamodel?
a. A model of data, about data
b. A model that describes the characteristics of an entity
c. A model that describes how enterprise architecture models fit together
d. None of the above
22. Which of the following statements best describes LiquidHub’s definition of the 5 key Application Architecture views or models?
a. Application Portfolio, Application-to-Business Capability, Application Security Model, Application Integration, Application Architecture Reference Models
b. Application Portfolio, Business Capability, Application Use Cases, Application Integration, Software Architecture Reference Models
c. Business Capability, Application-to-Business Capability, Application Use Cases, Application Integration, Software Architecture Reference Models
d. None of the above
23. Which of the following statements best describes LiquidHub’s definition of Information (Data) Architecture?
a. Information Architecture defines the business context, owner, content, format, and location of structured (e.g., database and XML) and unstructured (e.g. content) data
b. Information Architecture is the structure of an organization’s logical and physical data assets and data management resources
c. Information Architecture is the categorization mechanism for classifying data-oriented architecture and solution artifacts.
d. None of the above
24. The benefits of Information Architecture are all of the following EXCEPT?
a. Enterprise-wide information management principles and strategies
b. Rigorous definition of modular and common business processes
c. Common specifications and stewardship of key data
d. Use of and contribution to Industry-wide information standards
25. Which of the following statements best describes LiquidHub’s definition of Technology (Infrastructure) Architecture?
a. The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, application and information services.
b. The Technology Architecture describes the IT infrastructure, middleware and network standards of an organization.
c. The Technology Architecture describes the IT communications and processing standards of an organization.
d. All of the above
26. Which of the following statements best describes LiquidHub’s definition of an effective tool in which to implement Governance?
a. RACI Chart
b. Program Management Plan
c. Burn Down Chart
d. Requirements Specification Document
27. Which of the following statements best describes LiquidHub’s definition of Solution Architecture?
a. A Solution Architecture is a description of the business, providing a viewpoint of operational and change activity
b. A Solution Architecture is a pattern architecture of a reference model
c. A Solution Architecture is a “vertical slice” through all EA domains (layers) which aims to describe a focused business operation (capability, process, activity) and how IT enables it.
d. None of the above
28. Which of the following statements best describes LiquidHub’s approach to rationalizing enterprise application portfolios?
29. Which of the following statements best describes LiquidHub’s definition of the 5 key Technology (Infrastructure) Architecture views or models?
a. Technology Architecture Reference Model (Catalog), Application Infrastructure Architecture Model, Information Architecture Model, Distributed Computing Architecture Model
b. Technology Architecture Reference Model (Catalog), Application Infrastructure Architecture Model, Network Architecture Model, Distributed Computing Architecture Model, Storage Architecture Model
c. Data Center Model, Application Infrastructure Architecture Model, Network Architecture Model, Distributed Computing Architecture Model, Storage Architecture Model
d. None of the above
30. Who is most often credited with crafting the first EA methodology?
a. Jonathan Zachman
b. Al Gore
c. The Open Group Architecture Framework (TOGAF)
d. Steven Spewak
An interesting discussion re: “the ArchiMate Modeling Language and The Open Group Architecture Framework Impact Such Trends as Big Data and Cloud.” Some notable quotes and my comments are below.
Quote: “…role of enterprise and business architecture in helping enterprises exploit and manage technology and business transformation.”
Comment: Enterprise architecture includes business architecture. Hence, there’s no need to point out both in this snippet. I prefer“enable” to “exploit.” Architecture is about “architecting” the enterprise. “Managing”change or “transformation” is an entirely different domain and requires a different skill set. Enterprise Architect can architect the optimal solution, but managing the change from the current to future state is significantly dependent on an organization’s ability to change and include factors such as: culture, change management processes, financial resources, human resources, etc…
Quote: “…There is less of a focus on the traditional things we come to think of EA such as standards, governance and policies, but ather into emerging areas such as the soft skills, business architecture, and srategy…”
Comment: Business architecture isn’t an emerging aea. It’s been a domain of enterprise architecture for 20 years. If “strategy” refers to corporate and/or business strategy then this is an even older domain having been first formulated at the Harvard economics department in the 1960s.
Quote: “…big data, cloud…technology is available to enhance or provide new capabilities to our business.”
Comment: This is key – how to leverage technology to improve existing business capabilities and/or create (innovate) new business capabilities.
Quote: “…for making decisions and clear ways of visualizing the different choices in front of us.”
Comment: Enterprise blueprints are great ways in which to visualize the choices.
Quote: “…how these tools can grapple better with these multiple levels of complexity and then also bridge some of these communication gaps among different constituencies in these large organizations…”
Comment: Enterprise blueprints organized as ‘heat-maps’(e.g. business process vs. application) significantly aid in presenting complexity.
Quote: “…capability-based planning, a technique in EA to get their arms around this thing from a business-driver perspective…”
Comment: Capability is the buzz-word du annum. I define it as the people, process, information technology and non-IT assets (e.g., real estate, commodities, production equipment)
Quote: “…What we're working on right now is a significant new release, the next release of the TOGAF standard, which is dividing the TOGAF documentation to make it more consumable, more consistent and more useful for someone.”
Comment: I’d like to see TOGAF include contemporary blueprint examples – e.g., let’s see a property and casualty insurance business architecture; a P&C business/application heat map. This would make TOGAF much more usable and relevant.
Quote: “…Does that follow in your thinking that the data is actually more prominent as a resource perhaps on par with applications.”
Comment: Data has always been at the forefront of the IT industry – i.e., the field is called INFORMATION technology. Both “process” and “data” are significant in that they combine to create applications.
My experience in implementing TOGAF in a variety of firms, has led me to conclude that to be successful in "developing" an EA capability within an organization requires organizing TOGAF's 10 Architecture Development Methodology (ADM) Phases into Super-Phases or "Stages" since each requires a unique set of skills, experience and firm-specific knowledge.
Stage 1: “ENTERPRISE ARCHITECTURE PLANNING”
The Preliminary and Architecture Vision phases could be considered “Enterprise Architecture Planning” for an iteration of the ADM cycle. These phases address deliverables such as EA objectives, scope of the enterprise, EA terminology, EA-oriented decision rights, integration with other management frameworks (e.g., corporate strategy, SDLC, etc…) and other related artifacts.
Key skills: project scoping, firm culture, firm structure (e.g., centralized vs. decentralized), other management frameworks
Stage 2: "ENTERPRISE ARCHITECTING”
The Business, Information Systems (Application and Data) and Technology Architecture phases are the “enterprise” viewpoints. Current and Future State architectures as well as the associated gaps and risks are defined in these phases for each domain. Potential Roadmap components for each domain are defined in these phases.
Perhaps most importantly, cross-domain (i.e., heat map) analysis is performance in this phases. For example, which business processes are enabled by which applications.
Key skills: business strategy, business process analysis, industry-specific (e.g., insurance) application technologies (e.g., underwriting software applications), application integration techniques, data-oriented technologies (e.g., MDM) data analytics, firm-specific data, infrastructure technologies (e.g., SANs).
Stage 3: “ROAD MAPPING”
The “Opportunities and Solutions” phase consolidates and reconciles the gap analyses done per each domain. Ultimately, it highlights the work packages (e.g., program/projects) that are required to transition from current to future state. A high-level roadmap (a Gantt chart) is defined in this phase.
The “Migration Planning” phase details the business value, prioritization and sequencing of the work packages. A detailed roadmap is defined in this phase. The precise handoffs to project management and operations are determined here.
Key Skills: project scoping, project estimation, project dependencies, project prioritization, firm-specific perations
Stage 4: “SOLUTION ARCHITECTURE GOVERNING”
In Phase G, the EA team seeks to ensure conformance with the Target Architecture by implementation (solution, systems) projects. The project teams are architecting the solutions (systems) in this phase.
In Phase H, minor changes are addressed by the EA team. At some point, major changes may warrant starting a new ADM cycle.
Key Skills: project oversight, project rescue, project status, governance (decision-rights)
The "Business Objectives to Roadmap" Cascade helps organizations visualize the links between the 2 concepts.
First, the organization "defines the work to be done based on its objectives. This results in "work" which can be governed via "projects' or "operations." Projects are unique and temporary in nature (i.e., there is a beginning and an end). The purpose of a project is to attain its objective & then
terminates when its specific objectives have been attained. Projects are planned, executed & governed by a PM methodology (e.g., PMP). Operations are ongoing & repetitive. The purpose of an ongoing operation is to sustain business. Operations adopt a new set of objectives and the work continues. Operations are planned, executed and governed by an “operational manual.”
Second, the organization needs to prioritize the "work." Most organizations prioritize the 2 segments of work independently. This often can result in issues since an "operations" person might be needed on a project based on her knowledge of the particular subject domain.
Third, the organization needs to "schedule" the work. Since most organizations face some type of constraint (e.g., finance, resource, time, etc...) the list of prioritized work generated in the second step may need to be adjusted. The end result is a Gantt chart (aka a Roadmap) of prioritized work that the organization needs to complete in order to satisfy its objectives. It's that simple.
The value of Enterprise Architecture is that its utility does not diminish with the relentless evolution of information technology. Indeed, it provides an indispensable framework in which to analyze a wide-variety of information-oriented processing systems. For example, let’s leverage a modified, 5-domain enterprise architectural framework to highlight the tradeoffs associated with using the cloud for a business application. Let’s assume that we’re considering a SaaS deployment model for a personal automobile claims insurance solution (aka application).
Domain #1: Business Architecture
First, let’s consider the “business” and its “needs.” Business solution architecture is a discipline that is superior in eliciting and articulating proverbial business needs. In essence, it stipulates the key business goals, user-focused goals, organizational variables (e.g., people, culture, etc…), business processes and business rules. The key tradeoff in this architectural layer is typically, speed to deployment vis-à-vis degree of customization. Although, cloud computing can facilitate increased agility, it inherently lacks a deep degree of customization. Should a business need to quickly implement a new business service, a cloud-oriented solution could facilitate a rapid time to market. However, if this is a claims business service that is considered a competitive differentiator, a SaaS model might not be an appropriate one.
Domain #2: Data Architecture
Although cloud computing adds complexity to data security (i.e., location, transport, leakage, etc…) it adds increased scalability, recoverability (i.e., both disaster recovery and archiving)and processing capacity to our data architecture. In our particular case example, we would need to evaluate the nature of potential claims data and any regulatory factors associated with it.
Domain #3: Technology (Infrastructure) Architecture
Cloud computing enables increased elasticity for our solution. This pliability allows us to more accurately match the applications services (resources) to the demand without overpaying for excess capacity or losing an opportunity to address market demand. A key consideration here is the degree to which application services that are “bursty” or “spiky” are amenable to the cloud. Those that are less variable need not pay the cloud premium. In our example, the insurance carrier would need to consider the statistical probabilities of abnormal, large scale “tail” claim events.
Domain #4: Security Architecture
Security is usually portrayed as a challenge for cloud computing. All of the traditional on-premise security issues (e.g., data privacy, data compliance, intellectual property risk, etc…) apply. However, there are several benefits that the cloud may offer with respect to security (e.g., professional audits of providers). Many SaaS vendor providers have security analysts that are significantly more experienced than what their clients have in house. Hence, one could argue that a SaaS model would have enhanced security. Once again, considering the specific nature of our usage scenario would be required to best understand the cloud versus on-premises deployment tradeoff. For example, if the insurance carrier’s target audience was the ultra-high net worth category, then security (e.g., authorization, authentication, data masking, etc…) would probably play a significant role.
Domain #5: Financial Architecture*
Companies are often challenged to increase functionality of IT while minimizing capital expenditures. By purchasing “just the right amount” of IT application services on demand, an enterprise can avoid purchasing superfluous computing assets. It’s commonly understood that cloud computing technologies and business models offer compelling economic benefits, particularly in reducing capital expenses. The shift to operating expense however could be a cause for concern. The cost rises linearly with the business which, if the insurance carrier intends on serving a large market and capturing a large share of it, the operational expense nature of cloud computing could be a disadvantage.
Are there other “architectural” sub-domains that should also be considered in our analysis? Perhaps the ‘integration’ architecture layer would be useful to ruminate?
*note: a system’s financial architecture is a lens that is underutilized in the discipline of enterprise/solution architecture analysis.
Today’s New York Times article, Macy's Regroups in Warehouse Wars, is an excellent example of the integration of business strategy, technology, information technology and ultimately Enterprise Architecture.
From a business strategy standpoint the key issue for Macy’s is how does it compete with Amazon.com’s uber efficient distribution system? A key strategic insight, from the chief stores officer Peter Sachse: "We've spent the last 153 years building warehouses. "We just called them stores." Thus, in order to better manage inventory, Macy’s is fulfilling web site orders directly from “shipping centers” at its store locations. This will enable the firm to increase sales without buying more inventories. In addition, store shipments will reduce markdowns, improve margins and increase inventory turnover. This move reflects an industry-based, strategic shift from “multichannel” to “omnichannel” operations where web site operations are intensely integrated with brick and mortar stores.
From a technology perspective, robotic “pick and pack” machines are critical in high-volume, automated warehouse operations. Obviously, this would be cost prohibitive in most, traditional retail stores. Hence, Amazon has a huge margin advantage here.
From an IT viewpoint, advanced inventory and supply chain software (i.e., information technologies) would help to automate some of the new required functionality at the store levels.
Of course, what’s critical is a discipline such as Enterprise Architecture that helps to weave all of the above into a cohesive business capability.
In a previous post, I suggested that a business should evalute "shocks" to its architecture. So what “shocks” can a business expect in the future? Thomas Friedman’s, The World Is Flat: A Brief History of the Twenty-First Century analyzes the history of globalization and presents ten “flatteners” which suggests that the world is increasingly a level playing field in terms of commerce. Many, if not all of these 10 themes, are rooted in information technology or digitization: the Personal Computer, fiber optic cabling, HTML, browser, open-source paradigm, workflow software, search engines and VOIP.
Friedman’s original remedy, subsequent publications and various critiques focus attention on individual skill development and associated government training programs. While certainly interesting and obviously important at the national level, how should the modern-day business organization contend with these 10 flattening “forces?” And, perhaps more significant, how should business entities prepare for the unpredictable and dynamic “shocks” that will undoubtedly affect them in the future?
In fact, since Friedman’s original thesis, the Internet continues to enable the reshaping of the global marketplace and digitization of industries. Cloud computing, social media, mobility and data along with its related kin (i.e., business intelligence, predicative analytics and big data) are increasingly helping to fuel the acceleration and complete digitization of business activities, from product development to customer collaboration. And, infused among the twin powers of globalization and digital technologies new government regulations, industry compliance requirements and other market forces continue to surface.
So, the challenge is increasingly how quickly can a business change, re-orient, or transform its business to successfully navigate the current and future competitive market space?
The Misguided Architecture of a Bridge
According to Wikipedia, the 1940 Tacoma Narrows Bridge was the first incarnation of the Tacoma Narrows Bridge that spanned the Tacoma Narrows strait of Puget Sound. It opened to traffic on July 1, 1940, and dramatically collapsed into Puget Sound on November 7 of the same year. From the time the deck was built, it began to move vertically in windy conditions, which led to construction workers giving the bridge the nickname Galloping Gertie. Several measures aimed at stopping the motion were ineffective, and the bridge's main span finally collapsed under 40-mile-per-hour wind conditions the morning of November 7, 1940.
Next Generation Bridge-Oriented Architecture
Galloping Gertie’s collapse had a lasting effect on science and engineering. Next generation bridge architecture began to focus on mathematical modeling of the bridge as a series of masses connected by springs, dampers and other foundational elements. Skilled practitioners defined reference architectures for different bridge types (e.g., arch, suspension, etc…) which helped to accelerate successful bridge development. These models and architectures where used in a variety of integrated, analytical modes. First, a designer could evaluate different bridge materials for their individual performance (e.g., spring coefficient, moment of inertia, cost per lb.., etc…) characteristics using a custom built model, reference architecture or some hybrid model. Subsequently, the designer would evaluate the elements as a system. The “system’s” performance would not only be compared with the intentions (e.g., cost, location, etc…) of the bridge’s owner, but also the static and dynamic response of the bridge to external forces or “shocks” to the structure.
Next Generation Business-Oriented Architecture
Similar to architecting a bridge, a business can be modeled and then architected as a series of fundamental elements (e.g., people, processes, property, plant, equipment, etc…). To avoid business collapse or, better yet, create competitive advantage, executive management needs to understand the architecture of its business. They need to continuously evaluate the external business forces or “shocks” that might affect its integrity and evaluate what new elements should be incorporated into the business’ design. For example, if a new business technology surfaces, how should the business use it, if at all? Or, if a competitor partners with a critical supplier in a new market, should the business follow suit? Thus, similar to the descriptive representations (architecture) of a bridge (e.g., blueprints, bill of materials, etc…), business leaders need an equivalent set of illustrative artifacts. And, similar to the benefits of structural architecture, business model design and architectural analysis offers a compelling value proposition: alignment, integration and the capability to transform.
Alignment refers to the condition in which each fundamental element of a business is configured in such a way as to satisfy the business intentions of executive management. Effective alignment implies that management’s business objectives are fulfilled.
Integration implies that the web of relationships between fundamental business elements is arranged in such a manner as to satisfy the business intentions of executive management. Effective integration intimates that these business elements seamlessly interoperate. It’s generally better when these elements are normalized, standardized and shared (or reused) where relevant.
Transformation suggests that the business has the aptitude to change. Whether to improve product time to market metrics, realize greater cost efficiencies in its operations or enhance some other aspect of its competitive position, a successful business needs to be capable of adapting quickly. This transformation can happen by trial-and-error or can be approached with a sense of purpose. If the latter approach is preferred, then an architectural representation of the current business provides a transformation baseline. These business descriptions also help to communicate the intended future state, the scope of transformation or to manage the change. Ultimately, a key condition for effective transformation is how well business executives understand their business’ design in the context of its competitive environment and related shocks. Thus, they need to understand and practice Business-Oriented Architecture.
@RayBordogna opines on Enterprise Architecture concepts.