架构类型
经常听到系统架构、软件架构、信息架构、数据架构等等，那么怎么去区分这些概念呢？
附录
http://www.codingthearchitecture.com/pages/book/types-of-architecture.html
Types of architecture
Treat enterprise architectures with a pinch of salt
Architecture applies to various aspects of software systems development, understandably so given its generic and flexible terms of reference. The classification of an architecture into a particular type may be obvious from its context and is, arguably, irrelevant to its success. Nonetheless, it can be useful to have an understanding of the breadth of the discipline - it may also help to put the subject of these essays into perspective.
Consider the various types of architecture that the IASA Glossary lists:
|
|
We won't delve too deeply into the definitions provided for each of these here but it suffices to say that they refer to each other, overlap greatly, create cyclic dependencies and are subjective in places. This is probably a fair reflection of how the term "architecture" is understood within the industry, albeit with the added complication of people not necessarily agreeing on which words to use for each term. The IASA terms offer valuable insight but are perhaps a little overwhelming as a starting point and don't (yet) offer a lingua franca for the discipline.
Within the field of software development, several forms of "architecture" are commonly referred to and, as such, form a good basis for a more philosophical consideration of what "architecture" might mean. Since they are perhaps the more universally used and provide good coverage of the information systems domain we'll explore them further and use them as a basis for our terminology.
Technical Architecture
The term "technical architecture" is a common first attempt to describe architecture but without the need to be specific about what type of architecture you're referring to. Therein lies a failing when using this term: it is too unspecific to be particularly meaningful when discussing a responsibility or project requirement.
Formally, a technical architecture can refer to any of the "architectures" that a system may have. It is thus arguably a more general term than "architecture" which is commonly understood to mean "system architecture". Often thetechnical architecture is used to refer to the collection of architectures defined for a system.
Thus it is recommended to avoid using the term "technical architecture" when attempting to define a specific area of architectural concern.
It may well be that the term "technical architect" is popular as it doesn't pigeon-hole its owner. It may also be that the term "software architect" doesn't sufficiently elevate the architect from the development team to their satisfaction. In either case, the authors believe that software, if done properly, is nothing to be ashamed of and that "software architect" offers a succinct, if not complete, description of the skills involved in the sort of hands-on architecture that we typically undertake.
System Architecture
"System architecture" refers to the way in which desired functionality is met by hardware and software components as well as how these components relate to each other and the intended users of the system. The term "architecture" is often generically used to refer to the system architecture, at least within the context of software systems development. The system architecture can span several different business functions.
Since the system architecture deals with the system as whole it naturally focuses on the system-wide design decisions and similarities. While it needs to consider the implication of these decisions for individual business functions it may not resolve them fully within each so as to move those decisions closer to where they are best addressed, namely the application architecture relating to each function.
Application Architecture
"Application architecture" is really a subset of the system architecture. The scope of the application architecture, as opposed to the system architecture, is often determined by business function.
It is typical for the application architecture to be defined to a lower level than the system architecture, particularly as it needs to refine the system architecture to provide the design decisions that relate specifically to the business function rather than to the system as a whole.
Enterprise Architecture
Enterprise architecture is a term often mistakenly used by architects that work on "enterprise" systems or systems that involve components that are touted as enterprise-level. However, enterprise architecture is more concerned with mapping the business processes and needs to the technical capabilities of the organisation, including personnel, strategy, distribution and how the business' changing needs will be met.
The enterprise architect role is therefore extremely wide-reaching, being enterprise-wide, and requires careful inspection of all the business' functions and their strategic requirements. Many people may contribute to the enterprise architecture, but that doesn't make them responsible for it and thus doesn't make them enterprise architects.
Summary
It's worth being aware of the various types of architecture that are commonly mentioned, particularly within the context of your own organisation. Treat enterprise architectures with a pinch of salt - they are often just the system architecture or application architecture for some enterprise software.
http://www.quora.com/What-is-the-difference-between-Software-Architecture-and-Systems-Architecture
Software Architecture can refer to the structure of a code base: how it's broken down into packages, what the APIs and dependencies are, degrees of generality, reuse and modularity, and so on. It relates to the static, build-time composition of blocks into a finished binary.
Systems Architecture can refer to the structure of a service: how it's broken down into subsystems, how those break down into individual servers, how they communicate, how they handle the consistency and availability tradeoffs, how they balance durability and latency, how they scale and so on. It relates to the dynamic, run-time composition of blocks into a running service.
For an analogy to the world of real architecture, you might compare "how to construct a stadium" with "how to manage the flow of people through a stadium on game day".
"Finally we should say a word about software versus system architecture--that is, the architecture of software-intensive systems. This is a book about the evaluation of software architectures, but we often hear the question, 'Well what about the architecture of the syste, not just the software? it's just as vital.' We couldn't agree more. System architectures embody the same kinds of structuring and decomposition decisions that drive software architectures. Moreover, they include hardware/software tradeoffs as well as the selection of computing and communication dquipment, al of which are completely beyond the realm of software architecture. System architectures hold the key to success or failure of a system every bit as much as the software architecture does for the software. Hence, they deserve to be evaluated every bit as much and for exactly the same reasons.
"The methods presented in this book will, we believe, apply equally well to system architectures as to software architectures. if modifiability is a concern, the methods can be used to guage the expense of making changes over the system' ofifetime; if performance is a concern, the methods can be used to spot bottlenecks and problem areas in the system as well as the software; and so forth.
"Why, then, do we call it a book about software architecture evaluation? Because that is the realm in which the methods were invented, developed, tested, and matured. In the remainder of this book when we speak of architecture, you can always safely prefix it with software. You can prefix it with system depending on how applicable you feel the methods are to system architectures and how confident you are about our intuition in the matter."
To add my 2cents, I believe that of the decisions made during the design of a software intensive system, those decisions regarding software are far more numerous, less obvious, and influential over the qualities that will be expressed in the final product.
http://en.wikipedia.org/wiki/Software_architect
Software architect is a computer programmer who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.
Contents[hide] |
[edit]History
With the popularity of multi-tier application development, the choices of how an application can be built have also increased. Given that expansion, the risk that a software development project may inadvertently create a "new" end product that, in essence, already existed has grown markedly. A new 'software architect' role has become necessary during software development.[citation needed]
The software architect concept began to take hold when object-oriented programming (OOP) was coming into more widespread use (in the late 1990s and early years of the 21st century).[citation needed] OOP allowed ever-larger and more complex applications to be built, which in turn required increased high-level application and system oversight.
The main responsibilities of a software architect include:
- Limiting choices available during development by
-
- choosing a standard way of pursuing application development[citation needed]
- creating, defining, or choosing an application framework for the application[citation needed]
- Recognizing potential reuse in the organization or in the application by
-
- Observing and understanding the broader system environment[citation needed]
- Creating the component design[citation needed]
- Having knowledge of other applications in the organization[citation needed]
- Subdivide a complex application, during the design phase, into smaller, more manageable pieces[citation needed]
- Grasp the functions of each component within the application[citation needed]
- Understand the interactions and dependencies among components[citation needed]
- Communicate these concepts to developers[citation needed]
In order to perform these responsibilities effectively, software architects often use tools or standardized model and symbol sets such as Unified Modeling Language[dubious ] and OOP[citation needed] to represent systems or develop artifacts. UML has become an important tool for software architects to use in communicating the overall system design to developers and other team members, comparable to the drawings made by building architects.
[edit]Duties
The role of software architect generally has certain common traits:
Architect makes high-level design choices much more often than low-level choices. In addition, the architect may sometimes dictate technical standards, including coding standards, tools, or platforms.
Software architects may also be engaged in the design of the architecture of the hardware environment, or may focus entirely on the design methodology of the code.
Architects can use various software architectural models that specialize in communicating architecture.
[edit]
The enterprise architect handles the interaction between the business and IT sides of an organization and is principally involved with determining the AS-IS and TO-BE states from a business and IT process perspective. Unfortunately many organizations are bundling the software architect duties within the role of Enterprise Architecture. This is primarily done as an effort to "up-sell" the role of a software architect and/or to merge two disparate business-related disciplines to avoid overhead.
An application architect works with a single software application. This may be a full- or a part-time role. The application architect is almost always an active software developer[citation needed] .
Other similar titles in use, but without consensus on their exact meaning, include:
- Solutions Architect, which may refer to a person directly involved in advancing a particular business solution needing interactions between multiple applications. May also refer to an Application Architect.
- System Architect (singular), which is often used as a synonym for Application Architect. However, if one subscribes to Systems theory and the idea that an enterprise can be a system, then System Architect could also mean Enterprise Architect.
- Systems Architect (plural), which is often used as a synonym for Enterprise Architect or Solutions Architect.
The table below indicates many of the differences between various kinds of software architects:
| Architect Type | Strategic Thinking | System Interactions | Communication | Design |
|---|---|---|---|---|
| Enterprise Architect | Across Projects | Highly Abstracted | Across Organization | Minimal, High Level |
| Solutions Architect | Focused on solution | Very Detailed | Multiple Teams | Detailed |
| Application Architect | Component re-use, maintainability | Centered on single Application | Single Project | Very Detailed |
In the software industry, as the table above suggests, the various versions of architect do not always have the same goals.[1]
[edit]See also
- Systems architecture / Systems architect
- Software Architectural Model
- Software architecture
- Hardware architecture / Hardware architect
- Systems engineering / Systems engineer
- Software engineering / Software engineer
- Requirements analysis / Requirements engineer
- Systems design
- Electrical engineering
- Electronics engineering
- International Association of Software Architects
[edit]References
[edit]External links
http://blogs.tedneward.com/2007/09/20/Hard+Questions+About+Architects.aspx
| Hard Questions About Architects |
|
I get e-mail from blog readers, and this one--literally--stopped me in my tracks as I was reading. Rather than interpret, I'll just quote (with permission) the e-mail and respond afterwards
Wow. For starters, Shane, kudos to you for sticking to your guns, and for figuring out really quickly that this was clearly not a place you wanted to work--a lot of developers have a mentality that says that they need the company more than the company needs them, sort of a "job at any price" mindset. Interviews aren't supposed to be the place where candidates grovel and say whatever the company wants them to hear--an interview is supposed to be a vetting process for both sides. But on to your questions: How could their idea of an architect be so far removed from someone like myself? I can't answer this one solidly, but I can say that the definition of an architect seems to be vague and indiscriminate a term, only exceeded in opacity by the term "software" itself. For some companies I've worked for, the "architect" was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or "architect team") was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This "architect team" then lays down "corporate standards", usually based on "industry standards", with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them. A friend of mine on the NFJS tour, Brian Sletten, tells a story of how he consulted on a project, implementing the (powerful) 1060 Netkernel toolkit at the core of the system, to resounding success. Then, on deployment, the "architecture team" took a look, pronounced the system to be incompatible with their "official standards", and forced new development of a working product. In other words, the fact that it worked (and could easily be turned to interoperate with their SOAP-based standard, of which there were zero existing services) was in no way going to stand as an impediment to their enforcement of the corporate standard. Is architecture supposed to be facilitative or restrictive? Ah, this is a harder one to answer. In essence, both. Now, before the crowd starts getting out their torches and pitchforks to have a good old-fashioned lynching, hear me out. Architecture is intended to be facilitative, of course, in that a good architecture should enable developers to build applications quickly and easily, without having to spend significant amounts of time re-inventing similar infrastructure across multiple projects. A good architecture will also facilitate interoperability across applications, ensure a good code quality, ensure good maintainability, provide for future extensibility, and so on. All of this, I would argue, falls under the heading of "facilitation". But an architecture is also intended to be restrictive, in that it should channel software developers in a direction that leads to all of these successes, and away from potential decisions that would lead to prolems later. In other words, as Microsoft's CLR architect Rico Mariani put it, a good architecture should enable developers to "fall into the pit of success", where if you just (to quote the proverbial surfer) "go with the flow", you make decisions that lead to all of those good qualities we just discussed. This is asking a lot of an architecture, granted. But that's the ideal. What relevance do architects have today? Well, this is a dangerous question, in that you're asking it of one who considers himself an architect and technologist, so take this with the usual grain of salt. Are we just overpaid out-of-touch developers? God, I hope not. Fowler talks about architecture being irrelevant in an agile project, but I disagree with that notion pretty fundamentally: an architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests. And if anybody stands up at this point and says, "Hey, wait a minute, that's a pretty tall order for anybody to fill!", then you start to get an idea of why architects do, frequently, get paid more than developers do. Having to know the business, the technology at a high and low level of detail, keeping your hands in the code, and watching the horizon for new developments in industry, is a pretty good way to burn out any free time you might have thought you'd have. Granted, all of these answers notwithstanding, there's a large number of "architects" out there whose principal goal is to simply remain employed. To do that, they cite "best practices" established by "industry experts" as a cover for making decisions of their own, because nobody ever gets fired for choosing what industry "best practices" dictate. That's partly why I hate that term: it's a cop-out. It's basically relying on articles on popular websites and magazines to do your thinking for you. Inevitably, when somebody at a conference says the word, "Best Practice", listeners' minds turn off, their pens turn on, and they dutifully enscribe this bit of knowledge into their projects at home, without considering the applicability to their project or corporate culture. Nothing, not a single technology, not a single development methodology, not even a single tool, is alwaysthe right answer. In the end, I think what Shane ran into was an "architect" with an agenda and an alpha-geek complex. He refused to consider somebody with a competing point of view, because God forbid somebody show him not to be the expert he's hoodwinked everybody else at work to think he is. Unfortunately I've run across this phenomenon too often to call it statistical error, and the only thing you can do is to do exactly what you did, Shane: get the hell out of Dodge. |
http://msdn.microsoft.com/en-us/library/ee658098.aspx
Contents
What is Software Architecture?
Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance, security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application.
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman derived and refined a definition of architecture based on work by Mary Shaw and David Garlan (Shaw and Garlan 1996). Their definition is:
“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”
In Patterns of Enterprise Application Architecture, Martin Fowler outlines some common recurring themes when explaining architecture. He identifies these themes as:
“The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is.”
[http://www.pearsonhighered.com/educator/academic/product/0,3110,0321127420,00.html]
In Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman define architecture as follows:
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.”
[http://www.pearsonhighered.com/educator/academic/product/0,4096,0321154959,00.html]
Why is Architecture Important?
Like any other complex structure, software must be built on a solid foundation. Failing to consider key scenarios, failing to design for common problems, or failing to appreciate the long term consequences of key decisions can put your application at risk. Modern tools and platforms help to simplify the task of building applications, but they do not replace the need to design your application carefully, based on your specific scenarios and requirements. The risks exposed by poor architecture include software that is unstable, is unable to support existing or future business requirements, or is difficult to deploy or manage in a production environment.
Systems should be designed with consideration for the user, the system (the IT infrastructure), and the business goals. For each of these areas, you should outline key scenarios and identify important quality attributes (for example, reliability or scalability) and key areas of satisfaction and dissatisfaction. Where possible, develop and consider metrics that measure success in each of these areas.
Figure 1
Tradeoffs are likely, and a balance must often be found between competing requirements across these three areas. For example, the overall user experience of the solution is very often a function of the business and the IT infrastructure, and changes in one or the other can significantly affect the resulting user experience. Similarly, changes in the user experience requirements can have significant impact on the business and IT infrastructure requirements. Performance might be a major user and business goal, but the system administrator may not be able to invest in the hardware required to meet that goal 100 percent of the time. A balance point might be to meet the goal only 80 percent of the time.
Architecture focuses on how the major elements and components within an application are used by, or interact with, other major elements and components within the application. The selection of data structures and algorithms or the implementation details of individual components are design concerns. Architecture and design concerns very often overlap. Rather than use hard and fast rules to distinguish between architecture and design, it makes sense to combine these two areas. In some cases, decisions are clearly more architectural in nature. In other cases, the decisions are more about design, and how they help you to realize that architecture.
By following the processes described in this guide, and using the information it contains, you will be able to construct architectural solutions that address all of the relevant concerns, can be deployed on your chosen infrastructure, and provide results that meet the original aims and objectives.
Consider the following high level concerns when thinking about software architecture:
- How will the users be using the application?
- How will the application be deployed into production and managed?
- What are the quality attribute requirements for the application, such as security, performance, concurrency, internationalization, and configuration?
- How can the application be designed to be flexible and maintainable over time?
- What are the architectural trends that might impact your application now or after it has been deployed?
The Goals of Architecture
Application architecture seeks to build a bridge between business requirements and technical requirements by understanding use cases, and then finding ways to implement those use cases in the software. The goal of architecture is to identify the requirements that affect the structure of the application. Good architecture reduces the business risks associated with building a technical solution. A good design is sufficiently flexible to be able to handle the natural drift that will occur over time in hardware and software technology, as well as in user scenarios and requirements. An architect must consider the overall effect of design decisions, the inherent tradeoffs between quality attributes (such as performance and security), and the tradeoffs required to address user, system, and business requirements.
Keep in mind that the architecture should:
- Expose the structure of the system but hide the implementation details.
- Realize all of the use cases and scenarios.
- Try to address the requirements of various stakeholders.
- Handle both functional and quality requirements.
The Architectural Landscape
It is important to understand the key forces that are shaping architectural decisions today, and which will change how architectural decisions are made in the future. These key forces are driven by user demand, as well as by business demand for faster results, better support for varying work styles and workflows, and improved adaptability of software design.
Consider the following key trends:
- User empowerment. A design that supports user empowerment is flexible, configurable, and focused on the user experience. Design your application with appropriate levels of user personalization and options in mind. Allow the user to define how they interact with your application instead of dictating to them, but do not overload them with unnecessary options and settings that can lead to confusion. Understand the key scenarios and make them as simple as possible; make it easy to find information and use the application.
- Market maturity. Take advantage of market maturity by taking advantage of existing platform and technology options. Build on higher level application frameworks where it makes sense, so that you can focus on what is uniquely valuable in your application rather than recreating something that already exists and can be reused. Use patterns that provide rich sources of proven solutions for common problems.
- Flexible design. Increasingly, flexible designs take advantage of loose coupling to allow reuse and to improve maintainability. Pluggable designs allow you to provide post-deployment extensibility. You can also take advantage of service orientation techniques such as SOA to provide interoperability with other systems.
- Future trends. When building your architecture, understand the future trends that might affect your design after deployment. For example, consider trends in rich UI and media, composition models such as mashups, increasing network bandwidth and availability, increasing use of mobile devices, continued improvement in hardware performance, interest in community and personal publishing models, the rise of cloud-based computing, and remote operation.
The Principles of Architecture Design
Current thinking on architecture assumes that your design will evolve over time and that you cannot know everything you need to know up front in order to fully architect your system. Your design will generally need to evolve during the implementation stages of the application as you learn more, and as you test the design against real world requirements. Create your architecture with this evolution in mind so that it will be able to adapt to requirements that are not fully known at the start of the design process.
Consider the following questions as you create an architectural design
- What are the foundational parts of the architecture that represent the greatest risk if you get them wrong?
- What are the parts of the architecture that are most likely to change, or whose design you can delay until later with little impact?
- What are your key assumptions, and how will you test them?
- What conditions may require you to refactor the design?
Do not attempt to over engineer the architecture, and do not make assumptions that you cannot verify. Instead, keep your options open for future change. There will be aspects of your design that you must fix early in the process, which may represent significant cost if redesign is required. Identify these areas quickly and invest the time necessary to get them right.
Key Architecture Principles
Consider the following key principles when designing your architecture:
- Build to change instead of building to last. Consider how the application may need to change over time to address new requirements and challenges, and build in the flexibility to support this.
- Model to analyze and reduce risk. Use design tools, modeling systems such as Unified Modeling Language (UML), and visualizations where appropriate to help you capture requirements and architectural and design decisions, and to analyze their impact. However, do not formalize the model to the extent that it suppresses the capability to iterate and adapt the design easily.
- Use models and visualizations as a communication and collaboration tool. Efficient communication of the design, the decisions you make, and ongoing changes to the design, is critical to good architecture. Use models, views, and other visualizations of the architecture to communicate and share your design efficiently with all the stakeholders, and to enable rapid communication of changes to the design.
- Identify key engineering decisions. Use the information in this guide to understand the key engineering decisions and the areas where mistakes are most often made. Invest in getting these key decisions right the first time so that the design is more flexible and less likely to be broken by changes.
Consider using an incremental and iterative approach to refining your architecture. Start with a baseline architecture to get the big picture right, and then evolve candidate architectures as you iteratively test and improve your architecture. Do not try to get it all right the first time—design just as much as you can in order to start testing the design against requirements and assumptions. Iteratively add details to the design over multiple passes to make sure that you get the big decisions right first, and then focus on the details. A common pitfall is to dive into the details too quickly and get the big decisions wrong by making incorrect assumptions, or by failing to evaluate your architecture effectively. When testing your architecture, consider the following questions:
- What assumptions have I made in this architecture?
- What explicit or implied requirements is this architecture meeting?
- What are the key risks with this architectural approach?
- What countermeasures are in place to mitigate key risks?
- In what ways is this architecture an improvement over the baseline or the last candidate architecture?
For more information about the key principles of software architecture design, see Chapter 2 "Key Principles of Software Architecture."
For information about the incremental and iterative approach to architecture, baseline and candidate architectures, and representing and communicating the design, see Chapter 4 "A Technique for Architecture and Design."
Additional Resources
Bass, Len, Paul Clements, and Rick Kazman. Software Architecture in Practice, 2nd ed. Addison-Wesley Professional, 2003.
Fowler, Martin. Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
浙公网安备 33010602011771号