Architecture is a minefield. Architecture is not by definition high level and sometimes relevant details are of the utmost importance. It is not strange that the added value of architecture and architects within large companies and projects is under heavy pressure due to architecture failures at large and the emergence of agile approaches to solve business IT problems. Continue reading “Open Architectures do not work: The need for real open Architectures”
The Ultimate IT Architecture checklist
Smart people have been thinking on how to create IT architectures as long as there has been computers. Ideas come and go, however creating good architectures can still be complex and time consuming.
An architecture checklist helps in the governance process. Architecture checklists can become long, complex and time consuming in usage. However my aim with this architecture checklist is that it will help you and all your stakeholders involved in a simple way when you are dealing with architecture quality and risk aspects. Continue reading “The Ultimate IT Architecture checklist”
Overview of ISO 25010
(Figure:source ISO25010 document)
The material of ISO is unfortunate not open. But since quality matters and ISO 25010 is used heavily for managing quality aspects within business IT systems a short overview.
Functionality
Functionality: A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.
- Functional suitability: Degree to which a product or system provides functions that meet stated and implied needs when used underspecified conditions.
- Functional completeness : Degree to which the set of functions covers all the specified tasks and user objectives.
- Functional correctness : Degree to which a product or system provides the correct results with the needed degree of precision.
- Functional appropriateness : Degree to which the functions facilitate the accomplishment of specified tasks and objectives.
Reliability
Reliability: A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time. Attributes:
- Reliability:Degree to which a system, product or component performs specified functions under specified conditions for a specified period of time.
- Maturity : Degree to which a system, product or component meets needs for reliability under normal operation.
- Availability : Degree to which a system, product or component is operational and accessible when required for use.
- Fault tolerance : Degree to which a system, product or component operates as intended despite the presence of hardware or software faults.
- Recoverability : Degree to which, in the event of an interruption or a failure, a product or system can recover the data directly affected and re-establish the desired state of the system.
Performance Efficiency
A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.
- Performance efficiency: Performance relative to the amount of resources used under stated conditions.
- Time behaviour : Degree to which the response and processing times and throughput rates of a product or system, when performing its functions, meet requirements.
Resource utilization : Degree to which the amounts and types of resources used by a product or system, when performing its functions, meet requirements. - Capacity : Degree to which the maximum limits of a product or system parameter meet requirements.
Compatibility
Compatibility:Degree to which a product, system or component can exchange information with other products, systems or components, and/or perform its required functions, while sharing the same hardware or software environment.
- Co-existence : Degree to which a product can perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product.
- Interoperability : Degree to which two or more systems, products or components can exchange information and use the information that has been exchanged.
Usability
Usability:Degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.
- Appropriateness recognizability : Degree to which users can recognize whether a product or system is appropriate for their needs.
- Learnability : Degree to which a product or system can be used by specified users to achieve specified goals of learning to use the product or system with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use.
- Operability : Degree to which a product or system has attributes that make it easy to operate and control.
- User error protection : Degree to which a system protects users against making errors.
- User interface aesthetics : Degree to which a user interface enables pleasing and satisfying interaction for the user.
- Accessibility : Degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use.
Security
Security:Degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization.
- Confidentiality : Degree to which a product or system ensures that data are accessible only to those authorized to have access.
- Integrity : Degree to which a system, product or component prevents unauthorized access to, or modification of, computer programs or data.
- Non-repudiation : Degree to which actions or events can be proven to have taken place, so that the events or actions cannot be repudiated later.
- Accountability : Degree to which the actions of an entity can be traced uniquely to the entity.
- Confidentiality : Degree to which a product or system ensures that data are accessible only to those authorized to have access.
- Authenticity : Degree to which the identity of a subject or resource can be proved to be the one claimed.
Maintainability
- Maintainability:Degree of effectiveness and efficiency with which a product or system can be modified by the intended maintainers.
- Modularity : Degree to which a system or computer program is composed of discrete components such that a change to one component has minimal impact on other components.
- Reusability :Degree to which an asset can be used in more than one system, or in building other assets.
- Analysability : Degree of effectiveness and efficiency with which it is possible to assess the impact on a product or system of an intended change to one or more of its parts, or to diagnose a product for deficiencies or causes of failures, or to identify parts to be modified.
- Modifiability : Degree to which a product or system can be effectively and efficiently modified without introducing defects or degrading existing product quality.
- Testability : Degree of effectiveness and efficiency with which test criteria can be established for a system, product or component and tests can be performed to determine whether those criteria have been met.
Transferability
- Portability:Degree of effectiveness and efficiency with which a system, product or component can be transferred from one hardware, software or other operational or usage environment to another
- Adaptability : Degree to which a product or system can effectively and efficiently be adapted for different or evolving hardware, software or other operational or usage environments.
- Installability : Degree of effectiveness and efficiency with which a product or system can be successfully installed and/or un-installed in a specified environment.
- Replaceability : Degree to which a product can replace another specified software product for the same purpose in the same environment.
Note that when you do a critical review on ISO20510 you will find that missing in ISO25010 is:
- Functional requirements
- Compliance (e.g. with laws, standards) requirements
- Documentation, Support and Training requirements and of course:
- Project Timing requirements
- Project Budget requirements
Architecture Documentation Checklist
When creating business IT documentation (e.g. IT architectures/designs) following these rules will help for producing sound documentation:
- Documentation should be written from the point of view of the reader, not the writer.
- IT Documentation should be organized for ease of reference, not ease of reading. A document may be read from cover to cover at most once, and probably never. But a document is likely to be referenced hundreds or thousands of times.
- Avoid repetition. Each kind of information should be recorded in exactly one place. This makes documentation easier to use and much easier to change as it evolves. It also avoids confusion.
- Avoid unintentional ambiguity. In some sense, the point of architecture is to be ambiguous. However unplanned ambiguity is when documentation can be interpreted in more than one way, and at least one of those ways is incorrect. A well-defined notation with precise semantics goes a long way toward eliminating whole classes of linguistic ambiguity from a document. This is one area where architecture description languages help a great deal, but using a formal language isn’t always necessary.
- Standardize your documentation. Use always the same templates for the same documents within your organization. Even better: Make use of de-facto standardizations that also make sense for people outside your organization, since you will be working with many people outside your organization during the life cycle of your product. A standard organization offers many benefits. It helps the reader navigate the document and find specific information quickly.
- Record rationale. So document decisions made. Recording rationale will save you enormous time in the long run, although it requires discipline to record in the heat of the moment. It will prevent the same discussions over and over again and everyone knows why the chosen path is taken.
- Keep it current. Documentation that is out of date, does not reflect truth, and does not obey its own rules for form and internal consistency will not be used. Documentation that is kept current and accurate will be used.
- Review documentation for fitness of purpose. Only the intended users of a document will be able to tell if it contains the right information presented in right way.
Architectures References
The field of business IT Architecture is covered with many many methods, foundations, industry organizations and reference architectures. So whatever the specific domain you are active in use and re-use information already there as described a solid reference architecture. And do not forget: When you publish your architecture document on the web, make sure to use a common creative license, so others can improve, reuse and build upon your work.
| Link Categories Overview | |||
|---|---|---|---|
| Architecture magazines (6) | Architecture Methods (12) | Architecture organizations (16) | Architecture Patterns (2) |
| Cloud (4) | Example Architecture (1) | Foundation Architectures (3) | Guidelines (2) |
| Industry Architectures (6) | Microservices (3) | Mobile (1) | Principles (4) |
| Reference architectures (37) | Security architecture (8) | Software Architecture (2) | Standards (6) |
Architecture checklists
An architecture checklist helps in the governance process. Architecture checklists can become long, complex and time consuming in usage. However the aim with this architecture checklist is that it will help you and all your stakeholders involved in a simple way when you are dealing with architecture quality and risk aspects.
This architecture checklist is composed out of some critical questions that all relate back to the main goal of doing architecture in the first place.
Simple architecture checklist questions:
- Is your main goal covered and reached with this architecture?
- Does the architecture address operability?
- Does the architecture address the following quality attributes:
- performance
- availability
- maintainability
- modifiability
- security
- privacy
- testability
- operability
- flexibility
- Does the architecture address and use principles? E.g. business principles.
- Can implementation risks easily be derived out of your architecture deliverables?
- Are architecture reviews done in a structured way? Architecture reviews SHOULD be performed to increase quality, control costs and reduce risks.
- Is it clear what assumptions are used for your architecture? (Take explicit and implicit assumptions into account!)
Serverless Architecture
Staying up to date in the complex field of business IT trends is hard. Since I felt my knowledge of the AWS (Amazone Web Services) Cloud portfolio was no longer up to date I was happy to have the opportunity to visit the 2016 AWS Global Summit organised on the May 24 in the Netherlands. The number of visitors that this AWS Summit attracted was far beyond my expectations. But since this was my first AWS Summit experience I did not really know what to expect of course. Continue reading “Serverless Architecture”
Rapid Application Development and Architecture
Programming web applications and creating IT systems has long been a complex and slow job. Following the usual software engineering life cycles the development phase could not start before requirements were written, architecture was approved and a lot of Unified Modeling Language (UML) diagrams were drawn. So even before the project produced something of value tons of documentation was produced.
Due to the success of agile software development methods as e.g. scrum and devops often architects grown up with traditional development approaches, are experienced as a barrier for speeding up. So the role of traditional IT architects and architecture for creating solid design documentation has become under immense pressure. Continue reading “Rapid Application Development and Architecture”
How Security Personas will help you
One of the tools of IT architects and UX designers is to work with so called ‘Personas’. Personas are fictional characters created to represent the different user types that might use a system, website, product or service. Using personas is common practice when dealing with UX design. But when developing a security architecture for a new system, service or website security personas are also valuable to use. Security Personas force you to think different about the goals and behaviour of attackers that are going to hit your system. Continue reading “How Security Personas will help you”
Complex attack vectors
Good security is goal oriented. A good security architecture is tailored to your situation.
When defining a product or new (IT) service one of the key activities is to define your specific security requirements. Defining requirements is known to be hard, time consuming and complex. Especially when you have an iterative development cycles and you do not have yet a clear defined view of your final product or service to be created. Continue reading “Complex attack vectors”