Friday 06 September 2013
I have some experience with modelling IT architecture when working for a number of clients. What I found is that if infrastructure modelling is done at all, it is most often done using ArchiMate (which is supported by many tools like BizzDesign Architect, Sparx Systems Enterprise Architect, Abacus, etc.). The problem with ArchiMate is, however, that it is designed to model several architectural layers in coherence and not specifically the layers themselves.
Archimate does support the infrastructure layer, but only at a basic level - just like it supports application modelling at the basic level. When, for instance, the application layer is modelled in ArchiMate, the detailed design is typically done in another modelling language, like UML, which software developers use to write code.
Infrastructure designs, however, don't have a defined language like UML, and are therefore often drawn in free formats using Visio. Which is fine in most cases by the way. ArchiMate, as a global standard, is not very suited for formal infrastructure modelling (try to model virtualisation for example, or a high availability cluster), but it is the best we have at this point in time.
The best way to start using ArchiMate for infrastructures is to define infrastructure services (the services we provide to the applications, like file storage, or Internet access) and model the infrastructure components and their connections below that.
Friday 05 July 2013
4+1 is a view model designed by Philippe Kruchten describing the architecture of IT systems, based on the use of multiple, concurrent views.
Figure: 4+1 views
The 4+1 views describe a solution from the viewpoint of different stakeholders. The model contains the following views:
- Logical view - this describes the functionality that the system provides to end users
- Development / implementation view - this describes the system from a programmer's perspective and is concerned with software management
- Process view - this describes the dynamic aspects of the system, explains the system processes and how they communicate, and focuses on the runtime behavior of the system. The process view addresses issues like concurrency, distribution, integrators, performance and scalability
- Physical / deployment view - this describes the system from a system engineer's point of view. It is concerned with the topology of software components on the physical layer, as well as communication between these components.
- Use cases - this describes a small set of use cases, or scenarios, the fifth view. They are used to identify architectural elements and to illustrate and validate the architecture design.
Apart from software architecture, the 4+1 view descriptions can be used in infrastructure architecture as well. The 4+1 views define what should be documented and how (4+1 prefers using UML for this). It does not contain a process on how to create the documentation, like the SEI stack does.
Friday 21 June 2013
The Software Engineering Institute (SEI) of the Carnegie Mellon University has published several books and papers describing architectural methods for solution architecture. Although the SEI calls it software architecture, the presented methods can be applied to solution engineering in general, including infrastructure architecture.
The SEI does not present an overall methodology that can be followed, but rather provides a set of tools and methods that have proven to work in practice. Some of the methods published by the SEI are:
- Quality Attribute Workshops (QAW) - these workshops use the input of many stakeholders of the system to be developed to define the non-functional requirements of a solution (like performance, availability and security) in a way that makes quality attribute requirements SMART and testable.
- Attribute Driven Design (ADD) - this is an approach to defining a solution architecture in which the design process is based on defined non-functional requirements.
- Views and Beyond (V&B) - this defines how to document an system’s architecture so that others can successfully use it, maintain it, and build a system from it.
- Architecture Trade-off Analysis Method (ATAM) - this is a structured method for analyzing a documented architecture in four one-day workshops.
- Cost Benefit Analysis Method (CBAM) - this method aims at analyzing the financial aspects of architectures. It aims to quantify the financial benefits of a described architecture.
The SEI methods are very useful in infrastructure architecture. Especially the emphasis on non-functional requirements like performance, security and availability is very well in line with the work of an infrastructure architect.
Friday 07 June 2013
TOGAF stands for The Open Group Architecture Framework. It is an extensive method for establishing (Enterprise) Architectures. TOGAF is one of the few methods not developed by one company (like for instance IAF and DYA that are created by Capgemini and Sogeti respectively).The Open Group consists of a consortium of companies and institutions, developing many standards, including TOGAF.
TOGAF describes three types of architectures:
- Business architecture
- Information Systems architecture, which comprises:
- Data architecture and
- Applications architecture
- Technical architecture
The ADM is the heart of TOGAF. It is an architecture development method.
Figure: TOGAF ADM
The ADM method describes the steps to be taken to come to a complete enterprise architecture or a change to an existing architecture. Every step itself consists of (a large number of) smaller steps.
All steps can be performed sequentially; if in phase H it is concluded that a change of architecture is necessary, the ADM can be re-started from phase A.
It is also possible to use only a part of the ADM (for a particular change or project) or to do all of the ADM, but not all parts in an equally fine grained detail.
TOGAF is an open framework, of which the description can be found on the Internet. TOGAF is also published as a book (700+ pages!) which can be obtained from The Open Group. TOGAF does have a license structure; a fee must be paid if TOGAF is used in a commercial environment. Please check the website of The Open Group for details. For individuals TOGAF can be used under a free license.
TOGAF is an enterprise architecture framework, but it can be useful as a reference in an infrastructure architecture as well. Especially phases D, E and F of the ADM are relevant. Phase D (Technology architecture) is about describing the current and desired architecture and to find the gaps between them. Phase E (Opportunities and Solutions) explains how to create solutions from the desired architecture. And phase F (Migration planning) describes how to determine the projects needed to implement an architecture.
TOGAF also provides examples of architecture principles, stakeholder and requirements management, gap analysis, migration planning techniques and much more, all of them relevant for infrastructure architects.
But be aware that TOGAF is very detailed and complex. It is hard to comprehend and the text can be confusing at some places. Just pick out the parts that are useful in your project.
Friday 24 May 2013
In 1987, John Zachman created a model to help documenting enterprise architectures. The Zachman model is a classic under the architecture models, and one of the first ones. A picture of the model is shown below.
Figure: Zachman framework
The model has six basic questions (columns) which must be answered by each of six viewpoints (rows) in order to describe an architecture. The basic questions are: What, How, Where, Who, When, and Why, and the viewpoints are:
- Scope (as seen from a planner)
- Business model (as seen from a business owner)
- System model (as seen from a designer)
- Technology model (as seen from an implementer)
- Detailed Representation (as seen from a subcontractor)
- Functional areas (as seen from the functioning system)
This leads to a matrix with 36 cells. When the cells are filled an overview of the complete enterprise architecture is created. In the cells the document is stated. For instance, the “What” of a Technology model (as seen from the implementer of the system) is a document describing the physical data model.
The big advantage of the model is that it is well known by most architects. It creates a common vocabulary amongst architects and it organizes architecture descriptions quite well.
A drawback of the model is that it can lead to creating a large number op documents, when everything is described in full detail. Furthermore, the model is primarily meant for architects; it is not very suited for end users, developers, or management. It is basically a framework for architects only.
Infrastructure architects could use the Zachman framework to create documents to describe the infrastructure. The relevant fields for infrastructure architecture are grayed in the picture below.
Figure: Relevant fields for infrastructure architecture
Zachman describes no method for filling in the framework. TOGAF has an Architecture Development Method (ADM) that can be used for this.
The Zachman model was created when John Zachman worked for IBM (he is retired now), and IBM has put the framework in the public domain. Therefore no license is needed for using the Zachman framework.
Friday 10 May 2013
Architecture frameworks define how to organize the structure and views associated with an architecture. Architecture frameworks can be seen as best practices, describing how and what to describe when creating architecture documents.
Over the years a wealth of architecture frameworks has been created by organizations, both public (like the Departement of Defence’s DoDAF framework) and private (like Capgemini’s IAF ). Recently there has been a shift towards the use of TOGAF as a generally accepted de-facto standard.
Some of the best known enterprise architecture frameworks are the Zachman framework and TOGAF. While these frameworks are primarily targeted at enterprise architects, they do contain some useful material for infrastructure architects as well.
Most architecture frameworks are quite large. The description of TOGAF, for instance, encompasses about 700 pages and the Zachman framework uses 36 cells that each need a full document to describe. Because most frameworks provide an vast amount of knowledge and guidance, using an architecture framework can be quite intimidating.
In the solution architecture realm there are no comprehensive architecture frameworks available. There are however some best practices and de-facto standards when it comes to creating and describing architectures. Two of these are the SEI stack and the 4+1 views.
Architecture frameworks should not be used without modification and adaptation to your own environment and needs. Often architects "cherry-pick" parts of frameworks or combine frameworks to fit their needs. For instance, it is quite common to combine TOGAF with the Zachman framework. Frameworks should be seen as useful guidance, to prevent you from reinventing the wheel.
Which parts you need from a particular framework is dependent on many factors, like:
- Is your architecture implemented in a green field situation or are you dealing with an already existing architecture and IT landscape?
- Are you planning on migrating systems or are you planning on creating new systems?
- Do you run a consolidation project?
- Do you have to handle many changes in a large program or are you running one project only?
Based on the environment as stated above, the culture of the organization (is enterprise architecture already mature in the organization or is nothing in place yet?), and already used standards in for instance software development or project/program management, a selection for a framework can be made.
Wednesday 17 April 2013
A Denial of Service (DoS) attack is an attempt to overload an infrastructure (component) to cause disruption of a service. This overload can lead to downtime of a system, disabling an organization to do its business.
There are two types of DoS attacks: those that target the resources on a (web) server - a resource depletion attack, and those that try to consume all network bandwidth to a server (bandwidth depletion attack).
To perform a DoS attack, an attacker fires off a large number of requests to a (web) server, either normal requests, of malformed requests. Because of the high load the server needs to process, or because the requests fill up the request queues (like the TCP WAIT queue), the server either crashes, or gets so slow that in effect it is not functioning anymore.
Because usually one attacking computer alone has not enough power or bandwidth available to bring down a server or a cluster of servers, most of the time a Distributed Denial of Service (DDoS) attack is used. In this case the attacker uses many (end user) computers to overload the server (cluster).
Since nowadays attackers are often professionally organized, they use groups of computers that are infected by malicious code, called botnets, to perform an attack remotely. These botnets are readily available and can be ordered online (if you know where to look for these services). It takes only fifty dollars to buy you a small DDoS attack on a defined target these days.
There is not much we can do about this kind of attack when it occurs. Shutting down the connection to the Internet is no solution, as this has the same result as the DoS attack intended in the first place. Some ways to handle a DDoS attack are:
- In some cases policies can be applied that isolate bad portions of traffic from normal traffic(for instance, dropping all malformed TCP packets). But in most cases, when a website is under attack, the attacker uses normal web traffic, which cannot be isolated from normal users of the web site.
- Rejecting incoming connections and data from a particular attacking machine only works when the amount of attacking machines is relatively limited – this does not work for a DDoS attack that has typically thousands of attacking machines. In this scenario traceback mechanisms could be used that localize the origin of an IP data stream and apply filtering it as close to the source as possible. This can only be imlemented by ISPs.
- Another option is to implement extensive redundancy/load balancing in the system, for instance by outscaling webservers to a web farm in the cloud. This only works if it is well planned before an attack occurs.
- Since often spoofed IP addresses are used for a DDoS attack, another preventive measure can be to implement an extra network router in the network path that authenticates the source address of an incoming connection.
- Running a script to terminate all connections coming from the same source IP address if the amount of connections is larger than ten can help getting the attack under control.
- Changing to an alternative server (with another IP address) might also help.
- The receiving server can implement some delay when a new connection is established, slowing down the rate of new connections coming in.
- Or the receiving router or load balancer implements throttling on incoming connections to the server to allow at least some connections to work normally, providing a degregated service to clients.
More articles: See left pane.
Friday 12 April 2013
In solution architecture, architecture principles are the primary design rules of a system. They limit the design freedom for detail designers, builders, and users. For instance, an architecture principle for IT infrastructures could be to use Windows as the primary operating system for all servers. This principle makes the resulting architecture better manageable, as knowledge of only one operating system needs to be learned. At the same time, it limits the freedom of choice of components built upon the infrastructure: software only available for Linux cannot be used.
Architecture principles must be defined before starting a new infrastructure project. Usually the principles are generic and exist already. Principles should always be written down, including their motivation (why did we choose for this principle?) and implications (what freedom does this principle limit?).
Apart from architecture principles, design principles can be defined to limit the design freedom even further. As an example, design principles can describe how the naming of servers is organized. This is not architecturally relevant (since it is realatively easy to change later on and it can be decided at a later time), but still very important when creating a new IT infrastructure landscape.
After the implementation of the IT system, it is maintained by system managers, usually for many years. The architecture principles used when the system was designed must be used and guarded during the complete life cycle of the system to avoid instability of the system. Systems managers must therefore be familiar with the architecture principles of a system when they start managing it.