Product Architecture

12 Key excerpts on "Product Architecture"

• 

  eBook - ePub

  Resources, Technology and Strategy

  • Nicolai J. Foss, Paul L. Robertson, Nicolai Foss(Authors)
  • 2005(Publication Date)
  • Taylor & Francis

    (Publisher)

  In this sense, a Product Architecture is a more foundational concept in technology than a ‘product family’ targeted at a market segment (Meyer and Utterback 1993), because some kinds of Product Architectures enable families of products to be leveraged from a single architecture, while others do not. Architectures are also broader than ‘platforms’ targeted at a market niche (Meyer and Utterback 1993), because they may enable leveraging of product variations for several niches or even several market segments (Sanchez 1996b; Sanchez and Mahoney 1996; Sanderson and Uzumeri 1997). There are two fundamentally different architectural approaches to defining component interfaces in a product design, which will be distinguished here as conventional and modular approaches to creating Product Architectures. The essential differences between conventional and modular approaches to defining, designing and developing new Product Architectures are summarised in Table 6.1. As suggested in Table 6.1, the conventional product design process usually relies on extensive marketing research to suggest the specific product functionalities, performance levels and maximum price that will appeal most broadly to a targeted set of customers. Given a set of marketing-determined optimal product attributes, the objective of product designers is to create an optimal product design that provides the desired product attributes at the lowest possible cost or the highest possible level of product performance within a specified cost constraint. The Product Architectures created by a conventional product design process are typically complex designs in which technically separable functional components have been combined into integrated assemblies of components to increase performance and/or to lower costs

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  What Every Engineer Should Know about Software Engineering

  • Phillip A. Laplante, Mohamad Kassab(Authors)
  • 2022(Publication Date)
  • CRC Press

    (Publisher)

  Software architecture is significant in enabling software success for many reasons. In addition to helping reduce complexity, the study of software architecture is important to software engineers because it enables them to help stakeholders describe high-level structure (or structures) of the system. It is this structure that facilitates the satisfaction of systemic qualities (such as performance, security, availability, modifiability, etc.). A well-conceived architecture enhances the traceability between the requirements and the technical solutions, which reduces risks associated with building the technical solution. It also serves as a vehicle for communication to the stakeholders of the system under consideration and can serve as a basis for large-scale reuse. Defining software architecture involves a series of decisions based on many factors in a wide range of software development. These decisions are analogous to the load-bearing walls of a building. Once installed, altering them is extremely difficult and expensive. Therefore, each of these decisions can have a considerable impact on satisfying a project’s requirements under given constraints.

  The fundamental objective of this chapter is to help you develop a clear understanding of the significant role architecture plays in the development of complex systems. Another goal is to get you started in understanding the process for identifying an appropriate architecture before the software is designed, or to be used in redesigning a legacy system. While further study in this subject will be needed to truly become a software architect, we hope to interest you in that study. As with the foundation and framing of a building, a well designed and developed software architecture can result in a much more reliable, maintainable, and longer lasting system.

  4.2 Basic Concepts

  4.2.1 What Is Software Architecture?

  The word architecture is used in many different contexts. We hear terms such as enterprise architecture, cloud computing architecture, IoT system architecture, etc. The common underlying theme across these terms is that we are dealing with structures comprising elements and their properties, and that interact with each other to achieve some useful purpose.

  Interactions depend on how these elements are related to each other and the assumptions each makes about what the other provides. For example, in the case of enterprise architecture, we are dealing with an organizational structure. The business processes govern how the various divisions within an organization interact with each other. An interacting division makes assumptions about the services provided by the one it interacts with. A division, however, is less interested in the internal structure and functioning of another division it interacts with. All the divisions are, however, interested in how they communicate, coordinate, and collaborate to fulfill the mission of the enterprise.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Software Engineering Design

  Theory and Practice

  • Carlos Otero(Author)
  • 2016(Publication Date)
  • Auerbach Publications

    (Publisher)

  In a broad context, software architecture refers to both the process and design products required to systematically build software systems that meet their intended functions and quality. Of course, such broad definition of software architecture leaves out many of the details that make architecture essential in designing today’s complex software systems. To understand the meaning and importance of software architecture, it helps to examine how other engineering disciplines employ architectural designs to build complex systems with demanding functional and quality requirements. Consider the role of architecture in civil engineering, where designing and building structures such as houses, bridges, and high-rises is a nontrivial task. In these cases, architectural designs are used to specify the overall appearance of physical structures. When examined closer, it becomes evident that this broad definition is insufficient to describe to actual role of architecture in the process of building these ­systems, which involve far more than structural appearance. Architectural designs must also specify a variety of quality properties that make structures functional, safe, and economical. This requires architects to incorporate design alternatives that consider a wide variety of factors (e.g., social, aesthetic, and cost) supporting the needs of stakeholders, including the people who use these physical structures.

  In software engineering, architects work to create the overall design elements appropriate for supporting efficient refinement and construction of software systems. However, as in the previous discussion, architectural designs in software engineering involve far more than structural composition. They must also address numerous quality properties­ (e.g., performance, usability, and maintainability) that combine together to produce software systems that meet the quality expected by their stakeholders. To address these numerous concerns, software architects create different models of the software system, each addressing the system design from different perspectives. From the structural, logical perspective, the software architecture should address the needs of downstream designers and developers by decomposing the software (in an efficient manner) and defining the major components of the system, identifying their interfaces and interrelationships, and providing support for both functional and quality attributes of the system. From the configuration management perspective, the architecture should provide information about the hierarchy of files in the file system, their interrelationships, and the process for building one or more versions of the software system. From a systems engineering perspective, the architecture provides information about the physical deployment of the system, including the location of distributed subsystems, their interfaces and interrelationship, and specification of communication protocols between them. Other architectural perspectives exist for addressing various concerns that stakeholders may have and should be considered and designed for during the software architecture activity. Since the nature of stakeholders­ ­varies greatly in software systems, the perspective used to model the structure and behavior of software systems varies as well. Therefore, it is almost never the case that a single design element, from a single perspective, can represent the software architecture, especially for large-scale software intensive systems. In these cases, the collection of design elements and their detailed descriptions help form the software architecture. Formally, software architecture is defined as

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Reinventing the IT Department

  • Terry White(Author)
  • 2012(Publication Date)
  • Routledge

    (Publisher)

  I will say this again – I am not a technical person, so this will not be a technical discussion. Rather I will talk from a management perspective.

  There are many things that can be called an architecture. It often depends on the level of detail and complexity that you are examining. Hardware has an architecture, as do operating systems, transfer protocols and standards, as well as applications vendors. There are of course also data and information architectures as well. Much of the level that I picture is at an IT function level and at a business level – these are commonly called the IT architecture and the Enterprise architecture.

  In summary, you have three primary architectural levels:

  •   foundation level architectures, which define how the units are structured. These units are combined to form the IT infrastructure. There are levels within this level from microscopic architectures to application software architectures;

  •   business level architectures also have levels depending on chosen organisational and process boundaries. Thus you may have an architecture for the supply chain process, the customer service process, etc., which if you are wise all fit into the enterprise architecture – the overarching architecture that covers all that the company does in IT. You could go beyond IT in your architectural deliberations (I know a number of companies with architectures around which they organise their people, how they sell, and so on), but I'll stay with IT for the moment – it's complicated enough thank you;

  •   information architectures include how the data and processes are structured in order to carry out the work of the business.

  I looked up the term architecture in the dictionary, and apart from the expected building-related definitions they had this to say about architecture: ‘the conceptual structure and logical organisation of a computer or computer-based system1

  Sign up to read

  Learn more about book
• 

  No longer available |Learn more

  Software Architect's Handbook

  Become a successful software architect by implementing effective architecture concepts

  • Joseph Ingeno(Author)
  • 2018(Publication Date)
  • Packt Publishing

    (Publisher)

  Software architecture design involves making decisions in order to satisfy functional requirements, quality attributes, and constraints. It is a problem-solving process that leads to the creation of an architecture design.

  Software architecture design comprises defining the structures that will make up the solution and documenting them. The structures of a software system are made up of elements, and the relationships between the elements. The properties and behaviors of the elements that are publicly exposed, through an interface, should be identified as part of the design. The design allows you to understand how the elements behave and interact with each other. Private implementations of the elements are not architecturally significant and need not be considered as part of the design.

  The software architecture design serves as technical guidance for development and typically occurs iteratively until the initial architecture is at a point where the development team can begin their work. Once an initial architecture is designed, it can continue to evolve as development is taking place. For example, additional design iterations may occur to refactor an architecture to fulfill new requirements or quality attributes.

  Software architecture design is a creative process. Software architects have the privilege of coming up with solutions to complex problems and can use creativity to do it. It can be one of the most fun and rewarding parts of a software project.

  Passage contains an image

  Making design decisions

  The set of software requirements consists of a series of design issues that must be solved. For each of these design issues, such as providing certain business functionality, respecting a particular constraint, meeting performance objectives, or providing a certain level of availability, there may be numerous ways to solve the problem. You will need to consider the strengths and weaknesses of these alternatives in order to select the most appropriate choice.

  A large part of software architecture design is making design decisions to resolve issues so that a solution can be implemented. As the software architect, you will be leading the decision-making process.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Systems Engineering Guidebook

  A Process for Developing Systems and Products

  • James N Martin, A. Terry Bahill(Authors)
  • 2020(Publication Date)
  • CRC Press

    (Publisher)

  chapter two Systems concepts “Toto, I have a feeling we are not in Kansas anymore.” —Dorothy, in The Wizard of Oz Some of the basic systems concepts essential to effective implementation of the systems engineering process are described in this Chapter.9 2.1 Systems Terminology 2.1.1 Definition of System The term system is used to mean a set of integrated end products and their enabling products.10 The end products and enabling products of a system are composed of one or more of the following: hardware, software, personnel, facilities, data, materials, services, and techniques. 2.1.2 Definition of Architecture Architecture can be defined as: “The highest-level concept of a system in its environment. An architectural description is a model— document, product or other artifact—to communicate and record a system’s architecture. An architectural description conveys a set of 9 This Chapter (except for Section 2.5) is based on the original work of Richard Harwell, Dr. J. G. Lake, Dr. John Velman and the author in preparation o f the updated EIA standard on system s engineering (EIA 632). All rights are reserved. Used with permission. 10The terms end products and enabling products will be defined in Section 2.2.1. 17 18 Systems Engineering Guidebook views each of which depicts the system by describing domain concerns.” [SESC, 1996] So, an architecture deals with a system structure, its operational interfaces, profiles of use, and how the elements of a system interact with each other. An architecture can also be defined in terms of scenarios along with expected behavior for each scenario; states, modes and configurations of the system elements; and basic system purpose or mission. 2.1.3 Definition of Requirement A requirement is: (1) A characteristic that identifies the accomplishment levels needed to achieve specific objectives under a given set of conditions. (2) A binding statement in a document or in a contract.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Enterprise Architecture A to Z

  Frameworks, Business Process Modeling, SOA, and Infrastructure Technology

  • Daniel Minoli(Author)
  • 2008(Publication Date)
  • Auerbach Publications

    (Publisher)

  This includes the people, the assets, the systems, the software, the applica-tions, the practice, and the principles related to this function. 4 ◾ Enterprise Architecture A to Z product delivery, and distributed (if not virtual) inventories. Additionally, consumers want to be able to check product offerings, status, availability, account and billing information, to name a few, in real-time and literally from anywhere. The support of this kind of business landscape and customer experience requires a sophisticated modern IT capability that is based on architecture-driven principles. A firm that can put together such a tightly woven, information-comprehensive infrastructure is well positioned to become an industry leader. Stated differently, given the com-petitive environment, it is far-fetched to believe that a firm can be a leader in its space or prosper if it does not have a well-planned, well-architected, best-in-class IT apparatus. For example, consider the case of extending credit to consumers. If a firm can successfully perform data mining that goes deep beyond the openly available credit scores to establish a mul-tidimensional risk decisioning process in regard to extending a specific individual a credit line, whereas every other competitor relies only on the one-dimensional openly available credit score, then that firm can, perhaps, quickly become an industry leader and build a multi-billion-dollar operation. This data-intensive operation requires a well-planned, well-architected, best-in-class IT corporate capability. With a commodity, one can open up a product catalog or an online product portal, quickly determine which product meets one’s needs, quickly undertake a feature customization, and speedily receive the product for actual use or deployment within days. The procurement of PC products is an example of a commoditized function at this time, as also the online purchase of a luxury car, boat, recreational vehicle, or modular home.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Systems Architecting

  A Business Perspective

  • Gerrit Muller(Author)
  • 2011(Publication Date)
  • CRC Press

    (Publisher)

  However, some crucial details either from monodisciplinary area or from the cus-tomer or business contexts might have to be included. Quite often the devil is in the detail. Hence, known crucial details are part of an architecture description or model. Note that architectures do have a scope: System architecture captures the essence of a system in its context. Note that the system context includes the product family or portfolio. However, focus of the system architecture is on the system itself and, as such, will position this system in the broader portfolio. Family architecture captures the essence of the family of systems and its context. The focus is now on the family, explaining how different products can support spe-cific market needs and providing guidance to harvest the synergy between products. Portfolio architecture is similar to family but at a higher aggregation level. Architecting involves all activities to create an architecture: exploring details in systems and context, communication, design, specification, making decisions, etc. In other words, architecting combines external zoom-in and zoom-out (fact gather-ing and communication) with internal zoom-in and zoom-out (specification, design, integration). 2.4.4 REVISITING DESIGN AND ENGINEERING 10 0 10 1 10 6 10 5 10 4 10 3 10 2 10 7 monodisciplinary number of details system multidisciplinary Engineering Capturing all information that is required for logistics, manufacturing, legislation, maintenance, life-cycle support Design from needs and requirements to design: decomposition, interface definition, allocation, concept selection, technology choices anticipating engineering needs and constraints Figure 2.18 Positioning design and engineering in the dynamic range of abstraction levels.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  The Data Warehouse Lifecycle Toolkit

  • Ralph Kimball, Margy Ross, Warren Thornthwaite, Joy Mundy, Bob Becker(Authors)
  • 2011(Publication Date)
  • Wiley

    (Publisher)

  Chapter 5 Creating the Architecture Plan and Selecting Products

  In this chapter, we switch from the theoretical details of architectural components and services to the practical matters of how to actually design your architecture, select products to support it, manage the associated metadata, and establish the initial access security system. The first part of this chapter concentrates on the architecture design process. The architecture plan is the technical translation of the business requirements. It says, “these are the capabilities we must provide to meet the information needs of the business.” Once the plan is in place, you turn your attention to product selection—the process of comparing products to your functional requirements reveals who shines and who fades. The architecture and product selection are both critical inputs to the infrastructure map that we discuss toward the end of the chapter. Finally, once you have selected and installed the products, you must turn your attention to the initial metadata management and security tasks.

  Your job in creating the architecture plan is to identify the capabilities that are most important to your organization. Start with the highest priority business opportunity and determine what functionality you need to address that opportunity. Once you have this list of functional requirements, you can identify the vendors who provide these capabilities, and determine which is the best fit for your situation. If you start doing product selection before you understand the business requirements, you are doing it wrong and you are much less likely to succeed. Is this a clear and direct enough statement?

  The truth is, 90 percent of the time, the choice of products isn't a key determinant of overall DW/BI success. You can pick the best product, but if you use it to solve the wrong problem, nobody cares. Or you can pick a mediocre product, solve a high value problem, and be the hero.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Mastering e-Business

  • Paul Grefen(Author)
  • 2010(Publication Date)
  • Routledge

    (Publisher)

  high-level blueprint means that the focus is on the main, conceptual structures and not on small technical details. Again, this is comparable to other types of architectures: the architecture of a complex building or bridge is not specified in terms of individual bricks or nuts and bolts.

  We use the following basic definition of a general information system architecture:1

  The architecture of an information system specifies the structure of that system in terms of functional software components supporting specific functions and interfaces supporting the interactions among those components.

  The fact that an information system architecture describes software and interfaces means that hardware components (such as server machines) and physical connections (such as glass fiber links) between these are not part of the architecture. Hardware architectures exist too, but they are not in the scope of this book.

  As the definition states, an architecture describes a structure of a system. This means that we should use a clear way to represent that structure. Therefore, architectures are preferably described by means of diagrams (as opposed to a natural language textual description). There are specific diagram techniques for information system architectures, allowing specifying various kinds of characteristics. In this book, however, we use a simple notation. Later in this chapter, we will see examples of architectures.

  The concept of e-business information system architecture is a specialization of the general information system case discussed above. Obviously, the interfaces supporting interactions are of utmost importance in the e-business case, as e-business is about interactions between business parties enabled by automated systems (recall our definition of e-business from Section 1.2 ). In the rest of this book, we will use the term e-business architecture as an abbreviation of e-business information system architecture

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Enterprise Applications Administration

  The Definitive Guide to Implementation and Operations

  • Jeremy Faircloth(Author)
  • 2013(Publication Date)
  • Morgan Kaufmann

    (Publisher)

  Figure 6.6 , the application architecture for FLARP has a number of components that make up the overall enterprise application. These components all communicate through a common communication channel according to this design and route intra-application communications through this channel. In addition, any external communication from an interface perspective routes through another dedicated module of the application. These modules would not be easily identified by just focusing on the functionality of the enterprise application itself; therefore, it is important for any enterprise applications administrator to understand the application architecture in order to support the application correctly.

  The application architecture is very detailed from a technology perspective and focuses on how the enterprise application itself is designed and built. With an understanding of the application architecture, it is possible to trace issues through the application, know how to interface the application with other applications, and know how to best leverage the functionality provided by the enterprise application. In some cases it is the enterprise applications administrator who draws out this application architecture, but it’s usually the software developers and designers who create the application architecture to begin with. Regardless of the source, it is critical for any enterprise applications administrator to be able to both interpret and describe the application architecture for any application that they are responsible for.

  Technical Architecture

  Technical architecture deals with the most granular level of an enterprise application’s architecture. This area of architecture focuses on the individual technologies that make up the application’s technology stack including network, server, integration, and database technologies. Each of these elements is identified and documented as part of the enterprise application’s technical architecture.

  In order to determine the application’s technical architecture, we must first determine what the application’s needs are at the technical and business levels. These needs are generally presented in the form of technical requirements and nonfunctional requirements. The application’s technical requirements refer to the system-specific needs of the application. In the case of FLARP, let’s assume that the vendor has told us that it runs on a Linux platform, requires 4 GB of RAM for every 100 users of the interactive part of the application, supports Apache as a web server, and requires an Oracle DBMS back end. These technical requirements tell us exactly what the system needs in order to operate properly.

  Sign up to read

  Learn more about book
• 

  eBook - PDF

  Design Reuse In Product Development Modeling, Analysis And Optimization

  • Soh Khim Ong, Qianli Xu, Andrew Yeh Ching Nee(Authors)
  • 2008(Publication Date)
  • World Scientific

    (Publisher)

  A prevailing definition was given by Meyer and Lehnerd [1997] where a product platform is considered as “a set of 82 Design Reuse in Product Development Modeling, Analysis and Optimization subsystem and interfaces developed to form a common structure from which a stream of derivative products can be efficiently developed and produced”. This definition highlights three important features of a product platform, viz., (1) a common structure, which means that a platform must be shared by a group of to-be-designed products, (2) sub-systems and interfaces, which are the content of a product platform, and (3) efficiency in developing product variants, which is the desired benefit of a product platform. Based on this definition, the major concern is to exploit the technology core that enables the logic of platform commonality and product variant differentiation. Knowledge must be well-organized within the framework of product platform to provide decision support. Figure 4.1 The role of product platform in the spectrum of product development The core of the product platform is the Product Architecture, which is synonymous to the topology/layout of product functions and their embodiment. A Product Architecture refers to the scheme by which the product functions are mapped to the physical components [Ulrich, 1995]. The Product Architecture can be either integral or modular. Modular architecture has been repeatedly advocated because of its efficiency and flexibility in the management of complex systems. For example, different functions are delegated to different modules and product variants can be Process platform Product platform Fron t -end planning Functional Requirement (FR) Design Parameter (DP) Process Variable (PV) Customer Need (CN) Platform-based product development Customer do m ain Functional domain Physical domain Process domain Design of Product Platform 83 generated based on different combinations of the modules.

  Sign up to read

  Learn more about book