Description
Before defining Reference Architecture, it is better to have some idea about software architecture. Software architecture has various definitions which are derived from different sources. It ranges from designing, skapa och underhålla all kod för stora datorsystem att införliva alla hur de fysiska och logiska komponenter i affärssystem samt. Det är en kombination och interaktion av alla komponenter (mjukvara och hårdvara) att göra ett komplett system specificeras för olika företags behov.
The Reference Architecture and Fit/Gap analysis is a short of document stating the Reference Architecture to be used as the basis for the current project’s architecture and including the rationale for this decision. It is also a analysis process to understand the reference architecture and its implementation.
A Reference Architecture is a predefined architectural pattern designed for use in particular business and technical contexts.
Source of Reference Architectures within an organization can be any proven framework and asset used in earlier projects. The work product is generic and applies equally to selection of Reference Architectures from other sources.
The most important part of a Reference Architecture is to understand the fitness and gaps found during analysis.
A Reference Architecture Fit/Gap Analysis tabulates the key factors involved in selecting a Reference Architecture:
- Business scenarios
- Business drivers
- Architecture characteristics
Asset selection involves tradeoffs. Reference Architecture Fit/Gap Analysis documents the differences between the desired project architecture and the reference architecture in a statement-of-fit and identifies modifications required for the project.
Syfte
Nu låt oss kolla ändamål Fit / Gapanalys i Reference Architecture modell. Den Reference Architecture Fit / Gap Analysis används för följande
- Medverka till att fastställa omfattningen av en föreslagen lösning utvecklingsprojekt
- As an input to other architecture work products. Depending on the size of the gaps, the chosen Reference Architecture and associated fit/gap analysis may form the basis for the whole architecture.
- To highlight any gaps where the Reference Architecture does not fit project requirements. These indicate areas of risk or substantial architectural work required in the project. It also helps to select the reference architecture for the proposed project.
Impact of Not Having Reference Architecture
Selecting a Reference Architecture reduces the risk by reusing proven, best-practice solutions. Not applying a standard Reference Architecture increases project effort and cost, and increases the risk of project failure.
The best way to use architectural assets is to start by selecting a Reference Architecture. This will form the context for a more detailed selection of assets and guidance.
Reasons for Not Using Reference Architecture
On asset-based projects, this product should always be produced.
Om lämplig hänvisning arkitekturer är inte tillgänglig till ett projekt eller ett projekt beslutar att inte använda ett Reference Architecture, då som mest sammanfattningen, inbegripet orsaker en Reference Architecture inte valdes, should be completed. Often even this is unnecessary. A note can be added to the documentation of the choice of work products.
Hur Fit / Gap analys dokumenteras
En Reference Architecture Fit / Gap Analysis är grunden textdokument, med tabeller som bedömer kraven karakteristiska profil och ämnesområde täckning. Den tabellform beskriver alla nödvändiga poäng för att få en klar bild av den som avses arkitektur och dess lämplighet i det föreslagna projektet.
Sammanfattning: Kortfattad redogörelse för valda Reference Architecture och några större problem / risker.
Inledning: Inledande kommentarer om referensarkitekturen.
Nyckel drivrutiner: En kort redogörelse för de affärsmål eller begränsningar.
Arkitektur Krav Checklista: Dokumentet består av en standardiserad uppsättning frågor och möjliga svar om arkitektoniska krav, which allows a systematic collection of the architectural requirements for the project. This set is used as a checklist to prompt for customer architectural requirements and associated issues, som dokumenteras i en tabell, enligt nedan. Detta är ett exempel på tabell och det kan vara av ett annat format enligt standard av organisationen.
| Krav | Referensarkitektur Karaktäristik | Krävs Värde för Project | Risker / frågor / kommentarer Punkter att undersöka |
| Krav namn | Relevant värdeområde för denna arkitektur | Range tillämplig till kunden | Eventuella luckor, risker, sannolika framtida frågor, ämnen för efterföljande analys |
Subject Area Checklist:Varje Reference Architecture omfattar flera ämnesområden (ibland kallas "domäner"). Subject areas are specific areas of concern, till exempel, den webbaserade leverans kanal är ett ämnesområde som består av webbläsare, namnservrar, etc. A simple and clear way of examining the “fit” of a Reference Architecture to customer requirements is to compare it to the subject area coverage. Nedan följer en tabell för att fånga de detaljer.
Ämnesområde |
Närvarande i Arkitektur? | Krävs av kunden? | Problem / risker / Noter |
| Namn på ämnesområde | Yes/No | Yes/No |
Statement of Fit:A summary of the extent of “fit” between the Reference Architecture and customer requirements. Each Reference Architecture is described at several levels of abstraction, och vägledning ges på varje nivå på de stöds egenskaper. För varje område där Reference Architecture inte uppfyller kraven, Beskriv kortfattat:
- Den otillfredsställda krav. Detta är mycket viktigt för val av referens arkitektur.
- Typen och omfattningen av deltat som skulle vara nödvändiga för Reference Architecture för att uppfylla kravet. Också nämna om det behöver utökas, modifierad, eller får ett nytt ämnesområde?
- En uppskattning av kostnaderna och risken för deltat
Development Approach
Följande åtgärder bör vidtas för att generera detta arbete produkt:
- Identify the most likely Reference Architecture candidate. As there are a small number of Reference Architectures, var och en med en väl definierad fokus, Det ska vara enkelt att identifiera en eller två som är relevant för kundens projektmål och framtida affärsmodell.
- Granska beskrivningen av tillgången sammanhang, som finns i både text och illustration formulär, with the customer to assess fit. The illustrations, i synnerhet, are a powerful way of checking customer understanding of the proposed approach. During this process, the customer may decide to modify his previously stated requirements, till exempel, through recognition that the architectural pattern provided by the Reference Architecture is superior to the one he had previously envisaged.
- Use Business Drivers, IT Principles and Requirements lists to characterize customer requirements Check with the customer on whether there are any other important requirements that have not been covered by the standard characteristics.
- Examine the fit of the requirements with the characteristics provided by the Reference Architecture at various levels of abstraction.
- From the asset base, identify the subject areas covered by the Reference Architecture. Compare these with the subject areas required by the customer.
- Analyze the fit between the Reference Architecture and the customer requirements. Document all gaps, and make initial assessments with the customer on how these shortcomings will be resolved. This may involve:
- Extending the architecture (e.g., linking to an additional subject area)
- Modifying the Reference Architecture (i.e., changing its internal structure or behavior)
- Document the rationale for each of these decisions in terms of assumptions, business justification, risker, etc.
- Göra en samlad bedömning av lönsamhet och risk baserat på den information som finns på denna punkt.
Validering och verifiering
Utför följande kontroller:
- Kontrollera att kunden har godkänt de kriterier som används för att jämföra och välja Reference Architectures.
- Kontrollera att alla större kravområden hos kunden har ansetts.
- Verifiera att kritiska beroenden av arkitekturen i målmiljön kan uppfyllas.
- Validera eventuella kompromisser som görs tillsammans med kunden och Asset Providers med följande kriterier.
- Kontrollera att arkitekturen är motståndskraftiga mot förväntade förändringar.
