Front end architecture describes how business capabilities are exposed to employees, customers, and partners through the web, mobile, voice, and web services interaction media.
A thoughtfully designed front end architecture will result in bottom line productivity gains and top line growth improvements while improving time-to-market and lowering development and maintenance costs.
In your examination of front end architecture, you will first look at the “what” of the front end. This includes the benefits, goals, and capabilities required of the front ends that serve a wide variety of user groups and interaction media.
Next, you will turn your focus on the “how” of front end architecture, looking at an overall front end solution that satisfies the broad set of functional and non-functional requirements.
Finally, you will review guiding principles for successfully designing and implementing your front end architecture.
Why Focus on Front End Architecture?
The overall goal of front end architecture is to deliver business capabilities through efficient end user centered experiences that cross multiple user groups and interaction media. Common components are leveraged across user experiences where possible and practical.
What are the benefits that would be derived from realizing this goal?
First of all, end user productivity is improved by providing a seamless view of the content, data, and functions needed to perform a business role, linked to defined processes and procedures. Increases in end user productivity will directly benefit the bottom line.
Next, as the relationship between external constituents deepens through front end interactions, the top line grows. In the case of customers and partners, the front end, in a very real sense, manages the relationship between your organization and its partners and customers.
Finally, architecting an overall front end solution that thoughtfully reuses components across user groups and interaction media will result in faster time-to-market and lower development and maintenance costs.
With the potential benefits of front end architecture in mind, you will now focus on the requirements tied to achieving these benefits.
Front End Architecture: Desired Qualities
A solution architecture must satisfy a particular set of functional and non functional requirements. You will first consider the non functional requirements or quality attributes desired for the front end.
Certain qualities describe attributes of the architecture that can be measured and observed at run time, such as usability. Other qualities, such as reusability, can only be measured and observed at design time. You will first look at the desired run time qualities, and then the design time qualities.
Front End: Desired Run Time Qualities
Usability
The front end serves an organization’s employees, partners and, customers. Thus, the number one quality that must be satisfied through the front end architecture is usability. The ISO definition of usability is the efficiency, effectiveness, and satisfaction with which specific users achieve specified goals within a particular environment (ISO 9241).
Usability is tied to other run time qualities, such as performance and availability. A system isn’t very usable if it isn’t available, or if it doesn’t provide adequate interaction response time to its users.
Usability is paramount in achieving the bottom line and top line growth benefits. The front end architecture must always start with the end user, and then work its way back to the solution.
Medium Transparency
Another desired quality of front end architecture related to usability is medium transparency, defined as a consistent experience for the end user and all their interactions through the front end. These interaction media include web, mobile, voice, and web services.
There are many “cross medium” use cases that the front end architecture must satisfy. A few examples include:
- A customer beginning a transaction on the web and completing it over the phone with the assistance of an employee in a contact center
- A customer beginning a transaction on an interactive voice response unit and completing it on the web
- A partner completing a sales transaction on behalf of a customer, posting this transaction through a web service, with the customer later servicing their account on the customer website
From the discussion above, you should see that the desired run time qualities of usability and medium transparency are directly tied to the goals of improving bottom line results through productivity improvements, and top line growth through improving ease of doing business, allowing customers and partners to seamlessly interact through their preferred medium.
Front End: Desired Design Time Qualities
Next, you will look at the design time qualities of development scalability, “phase in” ability, reusability and maintainability, all of which are tied to delivering upon the goals of reduced time to market and lower development and maintenance costs.
Development Scalability
A front end architecture serving multiple user groups and interaction media is a very broad goal for an organization. As such, this architecture must allow for multiple development teams to contribute components that comprise the overall solution. The ability to scale development across multiple teams and to enable parallel development is a key requirement.
“Phase In” Ability
A quality related to development scalability is what you might call “phase in” ability. The front end architecture must allow functionality to be incrementally “phased in” over time—in a way that makes sense to the employee, customer, or partner. Legacy assets and packaged applications must be woven into the overall front end user experience, even if they may be “phased out” over time. This quality might be met in part by agile software development practices, but also by the architecture itself.
Reusability
Where possible and practical, the architecture should allow and promote reuse so front ends can be assembled and configured quickly for multiple user groups and interaction media. This is tied to the goal of reducing time-to-market and lowering development costs.
Maintainability
The architecture should be designed so the least amount of change is required to modify the functionality that is exposed across multiple user groups and interaction media.
Healthy Tension Among Qualities
Sometimes, it is not possible to achieve all the desired qualities in a given solution. Certain quality attributes are at odds with one another and compromises must be made. With front end architecture, a balance needs to be achieved between the run time quality of usability and the design time quality of reusability.
Reusability to an extreme would create a single web user interface component for each function. Because the same user interface may not be ideal for both employees and customers, this might compromise usability for certain user groups. However, usability taken to an extreme could lead you down a path where there are multiple redundant components, not necessary to achieve the stated top and bottom line goals, and at the expense of the time-to-market and total cost of ownership goals.
Consider that the word usability is contained in reusability. Once certain elements of a user interface are optimized for one user group, it many cases it will translate well to another user group.
A balanced approach can achieve both goals of usability and reusability. A practical strategy would attempt to reuse front end components first, customize by user group second, and create duplicate components as a last resort when necessary to achieve the usability goals of a user group.
Front End Functional Capabilities
Now that you have examined the goals and desired qualities of the front end architecture, you will review the high level functional capabilities required of the front end (see Figure 1).
Figure 1: Front End Functional Capabilities
Figure 1 illustrates how employee, customer, and partner User Groups utilize common capabilities through Web, Mobile, Voice, and Web Service Interaction Media.
Capabilities exposed through the front end architecture are divided into two categories: functional capabilities that span the Business Value Chain, and Supporting Capabilities.
Business Value Chain Capabilities are the functional capabilities core to your specific business. Example categories of Product Development, Customer Acquisition, Billing, and Customer Servicing are depicted here. Note that these capabilities wouldn’t be implemented in front end components, but exposed through them.
Supporting Capabilities are not specific to any one business, but generally needed in any front end architecture. Some of the supporting capabilities, like Security, span across all media. Others, such as Look and Feel management, are a capability specific to the web and mobile medium, although, the overall information architecture should be consistent across media.
Let me briefly review some of the other Supporting Capabilities. Content Management should be implemented in a way that new content can be easily authored, approved, and published. User Analytics is required to understand user behavior across user groups and media. End user analytics provide feedback for improving the end user experience on an ongoing basis. The other supporting capabilities listed are Search, Collaboration, Work Management, and Interaction History.
Front End Solution Architecture
You have examined the “what” of front end architecture; this included the benefits, goals, and capabilities required of the front ends that serve a wide variety of user groups and interaction media. Now, you will turn your focus on the “how,” looking at an overall front end solution that satisfies the broad set of functional and non functional requirements. You first will review the overall frameworks required of the front end, and then the reusable components built upon these frameworks.
Architecture Frameworks
An integrated set of architecture frameworks form the foundation of the front end solution architecture. Open source, commercial products, or homegrown frameworks may be used. Use of consistent and cohesive frameworks is tied to the development scalability quality because they enable multiple teams to contribute to the overall solution.
The overall front end solution is comprised of the Front End, Integration, and Back End layers. The architecture frameworks used within and across these layers are depicted in Figure 2.
Figure 2: Architecture Frameworks
Front End Frameworks
In support of the web and mobile media, a Portal framework is essential in assembling the overall user experience and in knitting together the capabilities across the business value chain as well as the supporting capabilities such as security, look and feel, content management, and search.
Other frameworks required of the front end include a Voice Portal framework to support the interactive voice response medium, and a secure Service Gateway framework to support partner and customer interactions through web services.
Finally, an Analytics framework is needed to capture end user analytics across medium.
Integration Frameworks
Front end components are loosely coupled from back end components. To interact with back end systems, an Enterprise Service Bus or ESB is used. Services exposed on the ESB can be utilized between multiple front ends.
There may be complex human-to-human, human-to-system, or system-to-system interactions to be managed. In this case, a Business Process Management or BPM framework may be required in addition to the ESB. This is directly tied to the Work Management supporting capability.
Back End Frameworks
The back end will include vendor packages and functional systems across the business value chain. It also should include a framework for Content Management and a Data Warehouse.
The Content Management system is used to author and publish content through front end medium. Content also needs to be searchable and may be tied to a search framework.
The front end Analytic framework captures only front end interactions. To enrich end user analytic data with the operational data needed for true customer insight, a Data Warehouse is needed in the back end.
Common
The vertical layer in the diagram shows frameworks that cross front end, integration, and back end layers. Infrastructure Monitoring ensures availability and performance service level agreements are met for all solution components surfaced through the front end. A Security framework externalizes security components from other layers and provides a common, consistent solution across all layers.
Thoughtful Component Reuse
Figure 3 shows some of the high level components that would be visible in the front end, integration, and back end layers of the architecture. Each of these components would be built upon the frameworks outlined above. The diagram is called “thoughtful component reuse,” because it illustrates how the architecture supports the design time quality goal of reusability.
Figure 3: Thoughtful Component Reuse
There are three portals, each customized to the needs of employees (B2E), customers (B2C), and partners (B2B). Each of these portals is created using a common framework. Portlets, reusable user interface components, are shared between the portals. Portlets may expose functional capabilities such as sales, service and billing, as well as supporting capabilities such as content management.
In the example above, the Sales Portlet is used across the B2E, B2C, and B2B portals. It may be configured differently to support the needs of the different user groups. The Sales Portlet in turn uses the Sales Interface in the integration layer to interact with the Product and CRM back end systems. The Sales Interfaces exposed on the ESB are identical to those used by the Voice Portal and Web Service Gateway.
Because components are shared across user groups and interaction media, the architecture fully supports the quality of medium transparency. When changes are required to the system, a minimal set of components will need to change, supporting the quality of reusability, and maintainability and in turn the goals of reduced time-to-market and lower development and maintenance costs.
Front End Architecture Guiding Principles
The six guiding principles outlined below should be kept in the forefront when developing your front end architecture:
1. Start with the end user and work backwards toward the solution
The best way to design a good user experience is to work from the “outside in,” from the view of the customer, partner, or employee as they interact through the front end. A thoughtful user centered design process models the user experience across user groups and interaction media. The goal of this process is to create a seamless presentation of all the functionality necessary to perform specified tasks, linked to defined process and procedures. Only a holistic approach will provide an integrated view of the user and all their interactions through the front end.
2. Realize the vision through an incremental approach
A “big bang” approach toward implementing the front end architecture will be very difficult to achieve due to the breadth and depth of the capabilities required. A phased approach with multiple teams building toward the vision is needed. At any point in time, an incremental release must make sense from an end user perspective. Return on investment (ROI) analysis should be used to determine which features are delivered in each increment. Vendor packages and legacy assets and should be thoughtfully integrated into the overall user experience.
3. Utilize a common technical framework
It will be impossible to realize the front end vision without committing to and utilizing a common set of technical frameworks as articulated in the previous section.
4. Develop a common delivery framework: People, Process, and Technology
An effective front end solution requires thoughtful attention to people, process, and technology to be successful. A common delivery framework is needed to operate on top of the common technical framework. Portfolio and program management are needed to identify reusable components and properly sequence deliverables. A shared delivery model will help scale development and improve the overall consistency and quality. Stewardship and operational roles are needed to manage incremental delivery of the user experience.
5. Thoughtfully reuse components across user groups and interaction media
Front end components should be reused across user groups wherever possible and practical. However, a one-size-fits-all user interface will not likely succeed in achieving the desired top and bottom line benefits because different user groups may require a different user interface to achieve its usability goals.
6. Utilize user analytics because you can only manage what you measure
User analytics are essential in ensuring the benefits are realized. The key metrics toward achieving ease of doing business must be defined. User analytics must be captured across interaction media and communicated through dashboards to provide a feedback loop on progress toward the ultimate goal.
Summary
You learned that business meets IT through the front end architecture.
Front end architecture describes how business capabilities are exposed to employees, customers, and partners through the web, mobile, voice, and web services interaction media. You examined the many benefits that can be achieved through a front end architecture including end user productivity gains, top line growth, reduced time-to-market, and lower maintenance costs.
A good architecture first considers the “what” or problem to be solved, and only then the “how” or solution. You examined the “what” through understanding the run time and design time qualities necessary to achieve the desired benefits and the functional capabilities needed across the business value chain. Then, you looked at the “how” or solution including the layers, frameworks, and components that promote thoughtful reuse.
Finally, I outlined six guiding principles to consider in implementing your front end architecture, with the first and most important principle being a commitment to start with the end user, and then work backwards towards the solution.
Has your organization focused on its end users and front end architecture? Does it understand the benefits that can be achieved? Has it defined and communicated its front end architecture? Is it being used to guide projects? If your answer is no to any of these questions, I hope you are inspired to take some of the thoughts outlined in this article and apply them to your organization. The rest is up to you!
About the Author |
|
|---|---|
 |
Jeff Ryan is an enterprise architect with twenty four years experience architecting and implementing thoughtful solutions to business problems. Jeff has served as the front end architect for a large financial services organization and this article reflects his experience in that position. Click here for a list of previous articles on enterprise architecture, SOA, Java, XML and XSLT. |
