System Architecture and Design Concepts

1. System Architecture and Design Concepts

2. System Architecture -- Definition A system architecture defines the capabilities required to produce IT products and services that meet clients’ business needs, describes how these products and services are to be organized and provided, specifies what IT resources they require, and identifies what common product and service components can be leveraged across the needs of multiple clients. • Defines capabilities required to produce products & services • Describes how products & services are organized • The architecture is driven by client business needs • The I/S Product Catalog helps map those needs to capabilities • Specifies what resources these require • Infrastructure • Application Systems • People • Identifies common components that can be leveraged

3. Potential Advantages of a System Architecture • To consistently meet the challenge of efficiently and effectively managing its resources, it is essential for an IT organization to identify and develop a well-designed and well-understood system architecture • A well-designed, well-understood, and well-managed system architecture: • Provides an active approach to developing and maintaining the strategic agility needed to address effectively the IT organization’s various clients’ needs and business opportunities • Helps organizations to avoid the undesirable outcome of the haphazard evolution of disconnected and inflexible systems • Provides knowledge about, and access to, reusable components that can be leveraged to reduce the amount of actual work needed to build the product

4. Advantages of a Good System Architecture (cont’d) • A well-designed, well-understood, and well-managed system architecture: • Makes complex systems more understandable and intellectually manageable by: • Providing abstractions that hide unnecessary detail • Employing unifying and simplifying concepts • Imposing a logical decomposition of the system • Ensuring the intellectual coherence of the various components of the system • Ensuring only the required minimum of logical coupling between different components • Reduce managerial complexity and makes the development of the system easier by: • Providing a natural (relative to the architecture) scheme for decomposing and assigning the work needed • Giving the various work components more coherence • Providing a clearer understanding of the various work product interfaces which reduces the work communication needs

5. Importance of Architects • Organizations can build competitive strength by identifying and developing individuals who have demonstrated through their experience and talents a particular prowess for system-level thinking about design • These individuals are typically known as architects • Their responsibility is to: • Make architectural decisions (from the big picture view) that protect the conceptual integrity of the architecture as it is developed • Guide the development of the system in ways that contribute to: • Increased efficiencies • More flexibility • Maintain and increase the ability to leverage for competitive advantages • In a nutshell, they make certain that all new projects fit within the existing architecture – this is a necessary constraint for success!

6. Architecture – Simplicity “There are two ways of constructing a software design: One is to make it so simple that there are obviously no deficiencies, and the other is to make it so complex that there are no obvious deficiencies. The first method is far more difficult.” • -- C. A. R. Hoare

7. The Six Major Design Concepts • Modularity • Loose Coupling • Reuse • Flexibility • Encapsulation/Data Hiding

8. Modularity • Systematically decompose a problem into smaller subproblems • Solutions developed in this way are implemented using structured programming • The typical structured program is subdivided into modules wherein a main module invokes the other modules as needed

9. Loose Coupling • Coupling is a measure of the strength of the relationship between modules • Loose coupling indicates a high degree of module independence • Loose coupling allows programming objects to come from completely different development processes and operate on completely different platforms, yet still function together • Cohesion is a measure of the functional coherence and focus of a module • Coupling and Cohesion are related: A first-order principle of software design is to increase cohesion and reduce coupling – which go hand-in-hand • Example of Loose Coupling: I/O Separation

10. Reuse • Build it once, leverage it many times • Loose coupling and tight cohesion increase the opportunities for reuse

11. Flexibility • Enables the support of a multitude of customers and platforms with a single version of code • Accomplished using variable data (parameters) or rules instead of “hard-coding” • Rules are ideally stored in relational databases such as DB2.

12. Encapsulation • Also referred to as data-hiding • Provides a form of logical data independence • Example 1: With encapsulation, the implementation of a type can be changed without the need to change any of the programs that use that type • Example 2: DB commands provide a degree of encapsulation in that a VSAM record, a DB2 row, or an IMS segment can all be accessed using the DB-OBTAIN verb

13. System Oriented Architecture (SOA)

14. SOA (rhymes with boa) Service-oriented architecture (SOA) - perspective that focuses on the development, use, and reuse of small self-contained blocks of code (called services) to meet all application software needs • Software code is not developed solely for a single application • Rather services are built that can be used and reused across all applications 7-14

15. SOA (continued) • Can extend SOA to the entire organization • An SOA organization would be… • Lean and agile using resources in the best way • Proactive in addressing changes in the market • Quick to respond and adapt to advances in technology • Transformational in its processes, structure and HR initiatives to match a changing, dynamic workforce 7-15

16. SOA Terminology • Service - chunks of code • A business task that can be reused • Search employee, check customer account, authorize credit • Multiple services make up a business process • Service provider • Whoever allows the service to be shared • Service consumer • Similar to a use case actor • Is who uses the service • Service registry • A catalog that displays and describes each service • Service contract or agreement • Registry also lists terms and conditions on how a service may be used 7-16

17. SOA (continued) • SOA focused specifically on IT • Customers • End users • Software development • Information needs • Hardware requirements 7-17

18. SOA (continued) Customers should be able to “plug and play” into your organization and have the same experience regardless of the channel End users should have access to whatever information and software they need regardless of where they (the end users) are 7-18

19. SOA (continued) Software development should focus on reusable components (services) to accelerate systems development. This means using component-based development methodologies. Information would be treated appropriately as a valuable organizational resource – protected, managed, organized, and made available to everyone who needs it. 7-19

20. SOA (continued) • Hardware is both integrated and transparent • SOA is programming language and platform independent: • plug and play. 7-20