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.
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.
Thursday 28 March 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.
Friday 15 March 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.
Friday 01 March 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.
Friday 15 February 2013
While all IT architects create, implement, and maintain some type of IT architecture, there is little consensus about the names of IT architects. Some of the often used names are:
- Enterprise architect
- Solution architect
- Information architect
- Software architect
- Infrastructure architect
- Security architect
- Project architect
- Systems architect
- Application architect
Since not everyone knows exactly what these people do and what their exact expertise is, I propose to use only two names: Enterprise Architect and Solution Architect. A clear distinction can be made between the roles of a solution architect and that of an enterprise architect.
Solution architects create IT solutions, usually as member of a project team. A solution architect is finished when the project is finished. Solution architects are the technical conscience and authority of a project, are responsible for the architectural decisions in the project and work closely with the project manager. Where the project manager manages the process of a project, the solution architect manages the technical solution the project builds, based on requirements.
Enterprise architects continuously align the overall IT landscape of an organization with the business activities the organization performs. Enterprise architects enable transformations of the overall IT landscape (including the IT infrastructure) over the years in a structured manner. An enterprise architect is therefore never finished (as opposed to the solution architect in a project, who is finished when the project is finished). Enterprise architects typically work in close corporation with the CIO and the business units, where they try to align the needs of the business with the current and future IT landscape. Enterprise architects build bridges and act as advisors to the business and to the IT department.
In short: Solution architects are the people that design, implement and deploy new (infrastructure) solutions in projects. Enterprise architects set the boundaries the solution architect has to stay within, based on business needs.
Friday 01 February 2013
Introducton
IT Architecture is a relatively new profession. Although the first use of the word architecture in IT systems is unclear, the term was used in Fred Brook's 1975 book "The mythical man month".
Fred Brooks was the project leader for the project leading to the IBM mainframe System/360 and the accompanying operating system OS/370. These were large projects (5,000 man years) where having an overall architectural of the systems were key to their success.
But the term architecture in IT systems only became popular many years later. In the 1990's software architecture became more widely used. Patterns were described for solving common programming issues, and languages were developed to describe architectures on a high abstraction level.
In 2000 the ANSI/IEEE 1471-2000: Recommended Practice for Architecture Description of Software- Intensive Systems became the first formal standard in the area of software architecture.
Definition
IT architecture describes the fundamental design decisions of an IT system and their rationale, usually at the beginning of a project or program. These are the things that are very hard and/or expensive to change later on in the project. An example could be the decision to use commercial products in a solution instead of in- house developed software. Another example is using a specific vendor for infrastructure components (for instance always using Hewlett-Packard as a supplier for servers).
Many definitions of architecture exists, many of which can be found on the site of the Software Engineering Institute (SEI) of the Carnegie Mellon University. However, the most accepted and well-known definition of IT architecture is the ANSI/IEEE Std 1471-2000, ISO 42010 “Recommended Practice for Architectural Description of Software- Intensive Systems” (also known as the IEEE1471):
Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
This definition has several components that are elaborated below.
The architecture must be fundamental to the system or infrastructure. For instance, the choice to use only Cisco equipment for network components is a fundamental choice (which cannot be changed easily later on), while the choice to use a certain version of the Cisco IOS operating system is something that can be changed at a later time or can be decided upon later.
Architecture describes a system that consists of components with their relationships. In principle everything can be seen as a system. An IT server infrastructure is a system, created from servers (components) that interact. However, the servers themselves are systems too, built of CPUs (Central Processing Unit), memory, power supplies, etc. - the components - that interact to behave as one server. CPUs can also be considered a system, with multiple cores, an Arithmetic Logic Unit (ALU), pipelines, caches, and so on.
The relationships between components of a system can also stretch beyond the system’s border. Systems can interact with other systems, outside of the architectural span of the system itself. For instance, the IT infrastructure of an organization (the system) is connected to the Internet, of which the organization has no control and which is considered to be out of scope of the system’s architecture.
Since architecture only describes the foundations of a system, principles are used to guide the design and evolution of the system. Architecture principles are the fundemantal rules the system is built upon.
Architecture principles limit the design freedom for the system's components. A typical architecture principle for IT infrastructures could be to limit the use of operating systems for servers to Windows only. This makes the resulting architecture better manageable, but limits the freedom of choice of components built upon the infrastructure: software only available on Linux cannot be used.
After the design and implemenaton, an IT system is maintained by system managers for many years. The architecture must be maintained and guarded during the complete life cycle of the system. Normally in its life cycle changes are made; the system unsergoes an evolution - it is enhanced or new interfaces are introduced. When the architecture is not properly governed the system could evolve from its original architecture into a more diffuse and disorganized architecture. Over the years, the systems appears to "fall apart".
More articles: See left pane.
There is also a 
