Architecture in information technology comes in different levels – enterprise, solution or software, and different domains – business, information, application, platform or infrastructure. The IT architect plays a crucial role in business transformation, system design & evolution and technological advancement by collaborating solution ideas and making sense of technologies.
Helping business with right technology and architecture involves the application of not only our left brains, but also right brains for aestheticism, communication and other factors. To manage the technology and architecture effectively, IT architects need to take a structured approach in their thought processes. This article presents a new tool called the CORE strategy, and highlights key considerations of architecture design with the C’s and P’s.
CORE Strategy
In information technology, we are in the mission of innovation and transformation. To accomplish this mission, technology leaders need to focus on capabilities and opportunities which will produce vibrant and sustainable solutions for strategy execution and business growth.
What do you do to pursue the opportunities in an organization? In my opinion, these opportunities can be realized by taking four actions – Consolidate, Optimize, Refresh and Enable (CORE) on organization’s technology and system portfolios.
These four opportunity vectors form the basis of a handy planning tool, which I call the CORE strategy. Inspired by Kim & Mauborgne [1]’s Four Actions Framework, the idea of CORE came from my experience as IT manager and architect. CORE is all about managing technologies, prioritizing IT spending and allocating resource on the basis of raising or creating capabilities (represented at right-hand side in the diagram), and reducing or eliminating cost & risk (represented at left-hand side in the diagram).
It should drive to get more bangs for the buck for the effective management of IT portfolio and program. Let me give you an example where a major US bank took the similar action to enhance customer experience and save hundreds of millions in cost. Its IT function consolidated several accounting systems (inherited from mergers & acquisitions) into a strategic target system in a multi-year transformative project.
 |
ACTION 1: CONSOLIDATE refers to the opportunity area where multiple solutions currently exist in the enterprise, but need to be rationalized and consolidated into one reusable, winning solution by eliminating redundant systems and platforms in order to save cost. Consolidation helps an organization identify what standards to move towards as they eliminate the silos and complexities they have built up over the years, along with the specific technologies, blueprints and reference models that will help them get there. Minimizing technical diversity and only customizing solutions that provide competitive differentiation is always a good option. This action is also known as “Rationalize”.
ACTION 2: OPTIMIZE describes the improvement opportunity where current solution is non-optimal in terms of performance, scalability, availability or cost etc., and need to find a better and efficient solution to remove performance bottleneck and raise the capabilities of business process. To transform and move the business forward, we have to come up with next generation solution which is faster, better and cheaper. System should be loosely-coupled and easily connectable using open and standard based technologies like service oriented architecture (SOA), instead of proprietary tools. Interoperability is a key consideration in optimization and consolidation initiatives.
ACTION 3: REFRESH (also known as “Renew” or “Upgrade”) pertains to the opportunity area where existing system or technology is waning, and need to be replaced or upgraded in order to reduce the risk and control the cost. Technology assets have a natural usable lifespan and need to be refreshed before that lifespan is reached. The costs of maintaining old technology sometimes exceeds to the cost of replacing the equivalent asset. For example, the maintenance costs of eight year old storage frame can exceed the costs of purchasing a new one. Technology capabilities continue to evolve on a rapid basis. Consider the browser technology with the latest HTML5 features. Upgrading employee’s browser to newer version is not a simple activity in the enterprise, as it may involve code change and testing in several core business applications. Recognizing, planning, and executing a technology refresh strategy will maintain the technology portfolio at an appropriate level to limit technology debt and balance investment.
ACTION 4: ENABLE represents the new opportunity area where a particular business or technology capability does not currently exist in the enterprise, and new service or solution needs to be introduced. Architects need to experiment, innovate and come up new solutions for future growth and strategic investment. They turn uncertainty into opportunity, generate insights, discover the job to be done and create business value by producing new products and services. Having a strategy for new & emerging technologies and platform incubation is crucial in today’s digital age.
C’s of Architecture
IT architecture is used to implement an efficient, flexible and high quality technology solution for a business problem in a cost-effective way. What do you consider in your mind while developing the architecture? In the IT industry, lots of people have tried to define architecture in the past. Despite having differences in the definition, there are certain common threads.
Perry & Wolf [2] defined the software architecture model as {Elements, Form & Rationale}. According to IEEE Standard 1471-2000 [3] and other researchers, software architecture represents the organization structure of a running system - embodied in its building blocks and characterized in their relationships to each other, and to external ecosystem environment, in order to satisfy the functional requirements and achieve a desired set of quality attributes. These structural building blocks are component, connector and content. In terms of structural characteristics or architectural relationship, they are represented by constraint, configuration, container and composition.
As per TOGAF [4] and other methodologies, enterprise or solution architecture focuses on discovering and delivering capabilities based on business scenarios and customer’s requirements.
In the end, architecture comes down to a list of C’s (see above in italics) which are the “what” part of architecture.
|
|
Component: Performs computation and processing, and transforms data internally. Theses structural building blocks are subsystems, processes, layers, object & service models, and usually represented as boxes. They provide main features and functionalities for the system. In Perry & Wolf [2]’s model, it is described as processing element, whereas Garlan and Shaw [5]’s model, it is called as component.
|
|
Connector: Enables the external and internal communication and interaction between components. These building blocks (usually represented as a line) concentrate on the integration interface, data-flow and the collaboration mechanics between components and external systems. Context defines the system’s dependency, integration relationship and process flow with external upstream and downstream systems in an end-to-end ecosystem environment. Examples of connector include message-transfer protocols, remote procedure calls. They are usually related to EIP patterns found in EAI domain. Perry & Wolf [2] describe it as connecting element, whereas Garlan and Shaw [5] describe it as connector.
Content: Is the data element that is transferred between the components via a connector, and reveals the application state. This data element provides the information view of system architecture, and is usually represented as message document. Examples include message, data model and data interchange format. Perry & Wolf [2] describe it as data element.
Constraint: Defines the properties and rules of relationship among interacting components, connectors and content (i.e. data) in order to achieve a desired set of quality attributes. They are usually introduced by the application of an architecture principle. Examples include statelessness in stateless service, uniform interface in REST. Perry & Wolf [2] describe it as form.
Configuration: Is a collection of constraints, and represents the overall structure of relationships among interacting components, connectors and data. Configuration can be named as a specific architectural style, such as REST.
Container: Is the runtime, live-in environment that provides uniform life-cycle management capabilities for architectural components. Spring’s DI/IoC framework is an example of container.
Composition: Defines how to compose a larger component from the several other components. Examples include front end composite service which is built using several backend services in SOA. Decomposition is just the opposite scenario, where a larger component is split into smaller components.
Choice: Architects explore and evaluate multiple design options (or choices), their pros & cons, trade-offs of one alternative over another before deciding or recommending the best possible solution of the business problem. The ability to explain ideas, rationale and the consequences of the alternatives is the key. Decision is usually governed by architecture principles and organizational technology standards. This can be compared with Perry & Wolf’s [2] rationale.
Customer: Is the people who has the stakes and interest in the computer system, and plays a key role in any architecture work by providing the business goals, use cases and requirements. Architect socializes the solution with stakeholders in order to garner support and establish consensus. Engineering solutions, architecture models and roadmap are reviewed and validated for viability to get their approval and buy-in. Customer & user experience is a key factor in overall solution space.
Concern: Is the key aspect of the system where stakeholders have interest, and determines the acceptability of the system. They are also known as architecture properties or quality attributes. Concerns are classified into two categories: vertical concerns such as functionality, usability and horizontal concerns such as security, validation, transaction etc.
Communication: Architects share and socialize their ideas and views with cross-functional teams in order to bring consensus for the proposed solution. Soft-skill plays a significant role in communicating and collaborating the design solution and deliverables effectively with business and technical communities.
Capability: Describes the ability of IT organization to perform certain business functions or meet customer requirements by using people, process and technology. Examples include customer relationship management (CRM), human capital management (HCM), enterprise resource planning (ERP), single sign-on (SSO) etc. Capability based modeling is used to transform business from one state to another for business execution and growth opportunities in enterprise business architecture.
Change: Is the only constant factor in today’s business environment, and need to be embraced and adopted quickly in order to be competitive in the market place. Architecture will be better off if it is easily configurable and based on common foundation and building blocks to enable agility and flexibility. Focus should be on not only build-to-last, but also build-to-adopt to meet the ever-changing business demands. Architect should play the role of change agent, as well as, change arbiter.
Challenge: Refers to the big issue we are facing currently in the organization or industry. In addition to business problem, sometimes architects face technical or design challenges. A good architect should be able to tackle these challenges effectively. Internet of things, mobile computing, big data, cyber security, and other disruptive technologies present new IT challenges.
Complexity: Is sometimes unavoidable in the enterprise. Architects should be able to identify the necessary system complexity and manage it by abstraction or decomposition. In the real world, complex systems evolve from simple working systems.
Cost: Minimizing cost and maximizing quality is everybody’s business in IT including architect. Architects need to find out the design options and decide a faster, better and cheaper solution. Efficient technology is always good for company’s bottom-line.
P’s of Architecture
In addition to structural building blocks and their relationships, architecture represents the principles and rationales governing system’s design and evolution (as per IEEE Standard 1471-2000 [3] and TOGAF [4]). These principles are usually formulated by the architecture board to manage IT governance and enterprise policies. Here is the highlights of architectural P’s which are usually the “why” part.
|
|
Principle: Describes the fundamental tenet of guidance to acquire, design, configure and manage technologies and services in an organization. These well-accepted rules exist in both architecture and design domains to drive the system’s design and evolution. For example, simple design is an architecture principle, whereas dependency injection is a design principle.
Policy: Companies formulate policies to mitigate risks and to meet legal and regulatory requirements and compliance. Architects should be cognizant to enforce those policies while designing the architecture.
Practice: Architects need to formulate and apply good practices and avoid bad practices while designing or implementing the architecture. Minimize distribution boundaries for objects is an example of best practice in object-oriented design to achieve performance.
Pattern: Is a proven implementation solution of a design problem within a given context, and usually named and documented in a consistent format. Patterns are applicable in both architecture and design space. For example, model-view-controller is an architecture pattern, whereas observer is a design pattern. Paradigm is sort of supper pattern and represents the architectural style like SOA, object orientation (OO) and representational state transfer (REST).
People: Technology alone cannot solve all business problems. Having a balanced mix of people, process and technology will create a winning and sustainable solution in the long run. To execute a business model, it calls for people with particular skills, mindset and experience. By investing in people, we build a strong & winning IT organization.
Process: Process plays a key role in business operational model. Architects need to standardize and integrate business and IT processes that will build the core capabilities for business execution and growth. Process should be lean, automated and of high quality.
Product: In addition to basic problem-solving skills and business fundamentals knowledge, architects should have domain knowledge on technology products, so that they can solve business problems more efficiently.
Passion: Architects should be passionate and energetic to learn and explore new and emerging technological trends. They need to experiment these technologies in their own center of excellence.
Pragmatism: Architects apply practical knowledge and common-sense approach by using a right mix of technology, process, and pragmatism to solve business problem.
Conclusion
Architects and technology managers should strive for better architecture and design which will survive the test of time and create the milieu for system use by thousands of users. CORE would be a compass tool to prioritize major initiatives, elevate business performance, drive technology direction, and design effective solution. This framework can help IT leaders align business decisions, and advance technology roadmaps and maturity without diving too deeply into tactical issues or getting bogged down into operational details. It should help architects to succeed and earn stripes in their roles.
Acknowledgement
I’d like to acknowledge my past and present colleagues and managers from whom I learned the nuances of architecture and management. A special thank you to Mark Little for his great review and feedback on this article. The ideas presented in this article are my personal opinions.
References
- Kim and Mauborgne: Blue Ocean Strategy - How to Create Uncontested Market Space and Make Competition Irrelevant. Harvard Business School Press, 2005.
- Perry and Wolf: Foundations for the Study of Software Architecture. ACM SIGSOFT Software Engineering Notes, 17(4), Oct. 1992, pp. 40–52.
- IEEE Standard 1471-2000: Recommended Practice for Architectural Description of Software-Intensive Systems.
- The Open Group Architectural Framework (TOGAF).
- Garlan and Shaw: An introduction to Software Architecture. Advances in Software Engineering and Knowledge Engineering, Volume I, World Scientific Publishing Company, New Jersey, 1993.
About the Author
Suman Pradhan is a senior IT professional with 20 years of experience in healthcare, financials and technology sectors. His research and interest includes architecture & technology management, information security, application development & management, and web, integration & distributed technologies. He is currently a technical architect at a Fortune 500 healthcare company based in Chicago, USA.