Vrijdag 07 Juni 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.
Vrijdag 24 Mei 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.
Vrijdag 10 Mei 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.
Woensdag 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.
Vrijdag 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.
Donderdag 28 Maart 2013
Each stakeholder in a project has his own point of view. In architecture these are called viewpoints. From a viewpoint a view on the architecture can be created.
There is no such thing as one architecture view. I have seen many projects that show me a usually large picture with many lines and boxes stating: "This is our architecture". This is nonsense. At best they are showing one view on the architecture. And sometimes not even that.
Usually the picture is meant for communicating the architecture to a certain group of stakeholders like project members, end users or management. The point here is that there is no such thing as "the architecture picture". There are only architectural views. And views are created from viewpoints.
Viewpoints can be seen as places from where an observer is located ("the viewpoint is that I am on top of a mountain"), and views are what can be seen from that viewpoint ("and from here I see the villages in the valley"). Other viewpoints ("I am standing in the valley") provide different views ("I see snow on top of the mountains").
The same goes for architectural views and viewpoints, where the observers are the stakeholders of the project. The viewpoint of end users of a system is completely different than the viewpoint of a system manager. And this viewpoint is completely different from that of a purchaser, a business manager or a business partner. They all look at the same system, but their views are radically different. For example:
- For an end user the system consists of user screens with buttons, reports, and other functionalities. They want the architecture of a system expressed as mocked-up screenshots. This gives them an impression of the system that is built and how it addresses their concerns.
- For a systems manager the system consists of software that is installed on hardware. The hardware and software must be configured. His view on the architecture will for instance be an overview of what software runs on what server and which network connections are active. He sees the configuration tool as a user interface.
- The purchase department sees the system as a bill of material for hardware and a set of licenses for software to be purchased.
Of course other stakeholders can have completely different views. The architect must express the architecture in various views to be able to communicate it to the various stakeholders. Not all views must be created at the start of the project- the view can be created when the need arises. It is important to remember that multiple views are needed to describe the architecture of a system.
Vrijdag 15 Maart 2013
Stakeholders are parties that have a relation to the system that is being built in a project. There are many stakeholders in a typical project. Some examples of stakeholders are:
- End users
- System managers
- Project members creating the solution
- Project manager
- Testers
- Business managers
- Financial department
- Vendors of IT systems
- System owners of adjacent systems
- Business partners outside of the own organization
In a project each of these stakeholders has concerns about the new system. These concerns are sometimes conflicting. Some examples of concerns are:
- End users are concerned with the useage of the new system - the way it will help them perform their daily tasks. The system must provide a fast and always available business service. End users should not be forced to perform tasks in a more complex way that absolutely necessary.
- System managers want to make sure the newly created system can be managed with the tools they already use. The new system must be fully documented and tested. The system must fit the technology already in place and it must run on already existing infrastructure. The system's components must be serviceable and vendor support must be in place. The system must preferably use proven technology.
- Project members creating the solution want freedom to create the system in a way that best fits their expertise (Java programmers want to develop in Java, not in .Net). They want the opportunity to find elegant solutions to design and build the system, if possible using the latest technology.
- The project manager wants to keep the scope of the project as small as possible to reduce project risk. He does not like changes to appear during the project. Therefore he wants to have as many interfaces out of his scope and make other parties responsible for the connectivity of the new system to other systems.
- Testers want the system to be testable. Therefore they want all parts to be defined in a SMART way (Specific, Measurable, Attainable, Relevant, Time bound). At the start of the project testers want the requirements to be fully clear and testable. Testers want the project team to produce test stubs for interfaces and repeatable test cases for functionality and non-functional aspects. They want to explicitly define all non-functional aspects of the system (like high availability and performance) in advance.
- Business managers want the new system to have ways to monitor the system on a high level using for instance KPIs (Key Performance Indicators). They want reporting capabilities for their superiors and their customers. They probably want the new system to have connectors to be able to connect to business partners.
- The financial department wants to use their knowledge in the purchasing process of the project. They want to be able to negotiate with vendors of IT solutions about terms and conditions and want to reuse already existing contracts with known vendors. They want the new system to be purchased from vendors the organization does business with already.
- Vendors of IT systems want their customers to use the latest technology they provide. They want to sell licenses and hardware. They want a long term relationship with their customers and want therefore to sell long term maintenance contracts.
- System owners of adjacent systems in the organization want the new system to seamlessly integrate with the systems already in place. They do not want to create new interfaces or perform many tests. It can be a challenge to get specialist staff appointed to the project, since they are usually busy with their own systems.
- Business partners outside of the own organization want the new system to follow their internal procedures and interfaces. They do not want to be bothered with the fact that a system is replaced by a new system.
The examples above are just a few of the concerns a few of the stakeholders have. In the real world many more stakeholders exist and the concerns may be much more complex. Therefore for a project to succeed proper stakeholder management is crucial.
Vrijdag 01 Maart 2013
Being a solutions architect requires more than a broad technical background. Social skills, management skills and leadership as at least as important.
In general, architects must be able to create a good working relationship with a diverse group of people. Not only project managers, project members, but also business representatives, system managers and enterprise architects. And they need sufficient management skills to manage the technical issues in a project. This includes making decisions on prioritization and handling unforeseen technical issues.
A solution architect must be seen as the technical leader in a project by not only all project members and the project leader (who needs to completely trust the architect on technical topics), but also by the other stakeholders of the project. There must be no uncertainty with senior management, the end users, or the system managers that the solution architect is the person to set the direction of the overall technical solution in a project.
This does not mean that the architect must be a specialist on all technologies used in the project, but he must have enough technical background and experience to be seen as a leader.
In order to perform as a true leader and technical manager I think solution architects should have more than ten years’ experience in IT related functions. This experience is necessary to gain confidence in their own skills, and to have enough technical background to value and create the architecture of a solution.
Experience is typically gained when working in various roles, leading to the architect role. This is why many solution architects have a so-called T- profile.
Figure: T-Profile
This means that they have a broad general knowledge in many technical areas (the top of the T- shape) and one technical area in which they are specialists (the vertical line in the T- shape). This specialism helps them not only in projects using that specific technology, but helps them also to understand technical specialists in general.
In case of an infrastructure architect the specialist knowledge should be infrastructures and the general knowledge should encompass the way the business works, the way applications are used, programming techniques, security procedures, etc.
Preferably, architects have worked for a number of organizations. This way they are used to working in various technical and cultural environments. Working in multiple technical environments helps the architect in understanding why certain solutions work well and others work less well. Also, the way a solution is created can vary from vendor to vendor. Being exposed to solutions built by multiple vendors helps architects value a given solution and help them coming up with new solutions based on earlier experience.
Working in multiple cultures is of much value as well. Working in a banking environment, for instance, is completely different then working in education or working for a production factory. In commercial environments making profit is key, while in the public sector public service is of much more value. Having experienced these differences, architects can be inspired to provide the best solution for most clients.
Meer artikelen: Zie de linkerbalk.
There is also an 
