Product Architecture

11 Key excerpts on "Product Architecture"

• 

  eBook - ePub

  Resources, Technology and Strategy

  • Nicolai J. Foss, Paul L. Robertson(Authors)
  • 2005(Publication Date)
  • Routledge

    (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

  Continuous Architecture

  Sustainable Architecture in an Agile and Cloud-Centric World

  • Murat Erder, Pierre Pureur(Authors)
  • 2015(Publication Date)
  • Morgan Kaufmann

    (Publisher)

  First, at the enterprise level, the architect must focus on defining the correct set of products and managing any overlaps and dependencies between or among them. In addition, as part of a product team, the architect has to drive the architectural decisions for the product. At the enterprise level, the architect needs to understand both the product roadmaps of each product as well as the underlying components and technology used for building them. The product roadmaps enable the architect to understand the capabilities being offered and planned by each product. She or he can then determine if there are any overlaps or key dependencies that have to be managed. This should be aligned with investment governance so that the organization is investing efficiently and not building similar capabilities in different products. The architect also needs to have a view on the internal components and technologies used for each product. This ensures that there is a consistent technology infrastructure and that products can leverage each other’s components where appropriate. We can summarize these two aspects by saying that the architect is responsible for ensuring the external and internal consistency and efficiency of the products within the enterprise. However, this responsibility should be handled in a flexible manner and not stifle the agility of the product development teams. From an external perspective, products need to meet their customer demand. Trying to be too strict to align products can result in unnecessary delays, which defeats the purpose of Continuous Architecture. The same view applies to being too strict on the internal components and technologies. You could also state that having a level of redundancy and competition among products is a good thing. This enables the organization to try different approaches and technologies to determine which one is most successful. We would only advocate such an approach for more mature technology organizations

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Managing the New Bank Technology

  An Executive Blueprint for the Future

  • Marilyn R. Seymann(Author)
  • 2020(Publication Date)
  • Routledge

    (Publisher)

  The scope of an enterprise architecture lies beneath the various application systems of a company, serving as a common platform or foundation. At the same time, it is positioned above the implementation details of particular computer hardware, operating systems, communication protocols, and other configuration-specific characteristics (see Figure 3). A more formal definition of architecture, as used within the discipline of systems architecture itself, might focus on the role of architecture in abstracting and delineating the essential (i.e., most useful) structure of the application systems domain into subsystems or components. From this perspective, architecture is defined as follows: FIGURE 3. Enterprise Architecture Scope The definition and design of the major components and boundaries (i.e., subsystems and partitions) of a system, including: ■ What do they do? > What services to they perform? ■ How are they used? > What are their external interface definitions? Making Choices: Architecture Principles and Models A systems architecture is shaped by the choice of a set of architecture principles, dictated by business criteria derived from industry and product requirements. Principles explicitly state the kinds of designs and approaches that will be emphasized in the architecture, and they provide guidance in making detailed implementation decisions as product and systems initiatives are executed as a part of a technology strategy. Principles are sometimes explained and amplified through models or pictures which bring to light important features of architectural components and the relationships and boundaries between them. The role of developing these models is an essential part of the process of defining architecture, because the act of envisioning models is the act of attaining an appropri ate grasp of the underlying realities being addressed in the architecture

  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
• 

  eBook - ePub

  The Concept of Enterprise Architecture from Theory to Practice

  • Tiko Iyamu(Author)
  • 2023(Publication Date)
  • Auerbach Publications

    (Publisher)

  The development of ETA, as proposed, is a four-stage approach: technical architectural requirements, classification of the domain, documentation of technologies, and formulation of governance principles. Technical architecture is developed for a specific purpose within a context. This makes it relative to the individual organisation’s strategy, aims, and objectives. However, there are generic fundamentals in the development of technical architecture. They include the following four main sequential steps.

  1. Technical architectural requirements.
  2. Definition of the domain.
  3. Documentation of technologies into current-to-strategic forms.
  4. Formulation of governance principles.

  7.3.3.1 Technical Architectural Requirements

  Technical architectural requirements are derived from the requirements contained in the business strategy. The requirements describe the basic functions required of ETA in supporting and enabling the business drivers (Shaanika & Iyamu, 2018 ). This is primarily to enable and support sustainability and competitiveness through governance and manageability (Ismagilova et al., 2022 ). The development stage also describes the components of ETA, including the inter-relationships and dependencies of the artefacts that constitute the architecture. It, therefore, gives a view of the sequence of the components involved in the development of ETA. The preceding introductory paragraphs demonstrate how ETA could be developed. This section focuses on the development, beginning with the definition.

  Technical architecture describes and defines systems and software into structure and categories (Venkatesan & Sridhar, 2019

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Handbook of Systems Engineering and Management

  • Andrew P. Sage, William B. Rouse(Authors)
  • 2011(Publication Date)
  • Wiley-Interscience

    (Publisher)

  12 System Architectures ALEXANDER H. LEVIS 12.1 INTRODUCTION Systems architecting has been defined as the process of creating complex, unprecedented systems (Rechtin, 1991; Rechtin and Maier, 1997). This description fits well for many of the systems that are being created or planned today, whether in industry, government, or academia. The requirements of the marketplace are ill-defined; rapidly evolving technology has allowed new services to be offered at a global level. At the same time, there is increasing uncertainty about the way in which they will be used, what components will be incorporated, and the interconnections that will be made. Generating a system architecture as part of the systems engineering process can be seen as a deliberate approach to cope with the uncertainty that characterizes these complex, unprecedented systems. More recently, the ability to interconnect systems by connecting them to information nertworks has generated the need to develop and implement architectures for systems of systems consisting of loosely coupled systems. The word architecture derives from the Greek word architecton, which means master mason or master builder. The architect, now as then, is a member of the team responsible for designing and building a system; then the systems were edifices, now they are computer-based and software intensive. Indeed, the system architect’s contribution comes in the very early stages of the systems engineering process, at the time when the operational concept is defined and the basic structure of the system is conceptualized. Consequently, the design of a system’s architecture is a top–down process, going from the abstract and general to the concrete and specific. Furthermore, it is an iterative process. The process of developing an architecture in response to requirements (that are ill-structured because of uncertainty) forces their reexamination

  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

  Beyond E-Business

  Towards networked structures

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

    (Publisher)

  Architectures of networked e-business systems are required to manage the complexity and efficient developments of these systems. Architecture has a pivotal function between business and organization aspects, on the one hand, and technology aspects, on the other hand. Architecture is also the basis for interoperability between e-business systems, both within an organization and between organizations.

  Architectures can be positioned along the aggregation dimension and the abstraction dimension. The position along the aggregation dimension determines the ‘granularity’ of the architecture (the size or scope of its components). The position along the abstraction dimension determines the concreteness with which components in the architecture are specified.

  The architecture of an e-business information system defines the structure of that system in terms of functional software components, supporting specific functions, and interfaces, supporting the interactions among those components. We identify three aggregation levels for networked e-business architectures:

  • market-level architectures describe the structure of e-business systems at the level of collaboration between multiple parties in an e-business scenario;
  • party-level architectures describe the structure of e-business systems within the boundaries of a single party participating in an e-business scenario; and
  • system-level architectures describe the internal structure of individual e-business systems.

  Party-level architectures are projections of enterprise architectures, because they describe the structure of the information systems supporting a single e-business scenario in which an organization (enterprise) participates.

  Reference architectures describe proven system structures that can be reused across organizations. Standard architectures describe system structures that are reused within a single organization. Instance architectures describe structures of concrete systems. Instance architectures can be based on standard or reference architectures. Standard architectures can be based on reference architectures.

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Strategy to Reality

  Making the Impossible Possible for Business Architects, Change Makers and Strategy Execution Leaders

  • Whynde Kuehn(Author)
  • 2022(Publication Date)
  • Morgan James Publishing

    (Publisher)

  On the other hand, business architects should have a strong working knowledge of technology, which has never been more important than it is today in our digital world. Successful architects think globally but act locally. They are not only concerned about their individual scope and scenarios, but they also think holistically and make sure that all the pieces fit together for an organization, both strategically and tactically. Business Architecture Benefits The fusion of the business and IT architectures helps to facilitate alignment between business and technology and ensures that architecture and technology decisions are business-driven. Business architecture frames technology discussions with a business lens. For example, instead of analyzing information at the system application level, it can be elevated to a conversation around capabilities. Business architecture also reflects business priorities. Value streams and capabilities inherently convey business priorities based on the objectives they are tied to as well as any metric ratings such as capability effectiveness or strategic importance. Any system applications or software services cross-mapped to these perspectives will inherit the business priorities. Business architecture also provides a shared business language and mental model that allows all parties to communicate, regardless of their business or technology perspectives. Business architecture helps IT architects engage strategically. Business architecture provides the business vocabulary for IT architects to speak the language of the business. In addition, the positioning of business architecture upfront in the strategy execution life cycle helps to engage IT architecture early as well

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Agile Model-Based Systems Engineering Cookbook

  Improve system development by applying proven recipes for effective agile systems engineering

  • Dr. Bruce Powel Douglass(Author)
  • 2021(Publication Date)
  • Packt Publishing

    (Publisher)

  detailed design individually optimizes those small design elements in terms of their structure or behavior.

  In this chapter, we will cover the following recipes:

  • Architectural trade studies
  • Architectural merge
  • Pattern-driven architecture
  • Subsystem and pattern-driven architecture
  • Component architecture
  • Architectural allocation
  • Creating subsystem interfaces from use case scenarios

  Let's get started!

  Five critical views of architecture

  There are five critical views, as shown in the following diagram:

  Figure 3.1 – Five critical views of architecture Each view focuses on a different aspect of the largest-scale optimization concerns of the system:

  • Subsystem/Component Architecture is about identifying subsystems, allocating responsibilities to the subsystems, and specifying their interfaces.
  • Distribution Architecture chooses how distributed parts of the system interact, including middleware and communication protocols. This includes, but is not limited to, the network architecture.
  • Concurrency and Resource Architecture details sets of concurrency regions (threads and processes), how semantic elements map into those concurrency regions, how they are scheduled, and how they effectively share and manage shared resources.
  • Dependability Architecture refers to large-scale design decisions that govern the ability of stakeholders to depend on the system. This is subdivided into the following three pillars of dependability:
    A. Safety Architecture

  Sign up to read

  Learn more about book
• 

  eBook - ePub

  Systems Thinking

  Managing Chaos and Complexity: A Platform for Designing Business Architecture

  • Jamshid Gharajedaghi(Author)
  • 2011(Publication Date)
  • Morgan Kaufmann

    (Publisher)

  In a global market economy with ever-increasing levels of disturbance, a viable business cannot be locked into a single form or function anymore. Success comes from a self-renewing capability to spontaneously create structures and functions that fit the moment. In this context proper functioning of self-reference would certainly prevent the vacillations and the random search for new product–markets that have destroyed so many businesses over the past years.

  Creation of the ability to continuously match the portfolio of internal competencies with the portfolio of emerging market opportunities is the foundation of the emerging concept of new business architecture (Figure 9.1 ).

  Figure 9.1 Self-renewing capabilities.

  Business architecture is a general description of a system. It identifies its purpose, vital functions, active elements, and critical processes and defines the nature of the interaction among them. Business architecture consists of a set of distinct but interrelated platforms creating a multidimensional modular system. Each platform represents a dimension of the system signifying a unique mode of behavior with a predefined set of performance criteria and measures. Designing business architecture follows the general rules of interactive design described in Chapter 7 . It therefore starts by assuming that the system to be redesigned has been destroyed overnight but that everything else in the environment remains unchanged. The designers have been given the opportunity to design the system from scratch.

  Figure 9.2 outlines the process of designing business architecture.

  Figure 9.2 Schematic outline of a design process.

  9.1. The system's boundary and business environment

  The first step in designing system architecture is to define the system's boundary and appreciate the environment in which it intends to operate.

  To define a system's boundary we need to understand the behavior of its stakeholders. A stakeholder of an organization is any individual or group who is directly affected by what the organization does and therefore has a stake in its performance. Therefore, we need to know the following: Who are the major stakeholders? What are their expectations? What are the desired properties of the system from their perspective? What is their influence? Which critical variables do they control (or influence)? For example, in a market economy the customer provides the operating income, the boss defines the membership, stockholders pay the capital, suppliers are the source of complementary technologies, and distributors provide access to customers. However, stake and influence do not necessarily go hand in hand; a high stake is often coupled with low influence, and vice versa. For example, customers with the highest level of influence (refusing their patronage) show a very low level of stake in the system. On the other hand, employees with a very high stake in the system often have low level of influence. Shareholders with very high influence have the least at stake. If unhappy, they simply take their money out.

  Sign up to read

  Learn more about book