Cloud computing is a model where the storage and computing capacity is provided as a service, usually on the internet, in a remote accessible fashion to heterogeneous parties.

The main drive to use cloud computing by these heterogeneous parties is cutting costs by the economy of scale and simplicity of maintainability. Maintainability is in essence the flexibility/changeability of a product/service during it’s life-cycle.

As a solution architect you are responsible to find the cheapest way to realize the current and possible future requirements of the business during the life-cycle of the product/service. Because cloud computing is about reducing costs, you should have a good look at it whether to use it or not.

The following part of this blog post describes several key choices to determine if and which cloud computing solution could be used for the product/service the company wants to provide. After the key choices, three cloud promises are described which have to be kept in mind while designing the product/service.

Choice between public/private cloud
Suppose a cloud (private or public) solution does not violates any of the corporate architectural principles, the following step in the investigation is to determine if a public or private cloud computing solution could fulfill the needs. The choice for private or public cloud will be mainly data security and privacy driven, like legal compliance, corporate principles, but also network latency and the available skills within the company to create and maintain a private cloud.

 Read more

This Blog is a kick off to for many writings about architecture in an Agile World. We will explore the topic from all the views possible, in order to gain a better understanding about it. By doing so, we hope to create a community of followers, who would also like to contribute or discuss about this topic.

Xebia is helping many organizations in the Netherlands, France, the United States and India with implementing an agile way of system development. In most of the cases the Scrum method is applied and very good results are achieved. Business and IT are working much closer together, resulting in more quality and much more customer satisfaction. However, lately we also see a trend in problems that seem to occur in (almost) every organization. Software is developed in a fast way with high quality, but it takes forever to get it in production. The more teams are being formed, the more interdependencies between the teams occur Read more

Last week I got a presentation for a security device I had never heard about.
Most times this means it is something which is not commodity, or has no real use-case.

But this time I was really impressed. The device is a possible replacement for IBM Datapower XML Security Gateway. But the way they designed the device is totally different.

What CrossCheck networks did was creating a device with just security as main use case. First of all it was an XML gateway, nowadays is does support HTML, XML, SOAP, FTP, JMS and others.
It also translates different flavors of JMS to each other, it can even convert from IBM MQ to JBoss MQ directly.

 Read more

In my last blog I presented an illustration which shows the two primary aspects of the architects’ role. On one side they play a role in strengthening the heartbeat. On the other side, they play a role in envisioning the future.

The focus in this blog is on the solution architect or application architect. The way the Enterprise architect deals with Scrum will be explored more in detail in a later blog. This blog combined with the previous 3 blogs can be also downloaded as a whitepaper from the Xebia website: http://www.xebia.com/architects_scrum

What is the role of the architect?
Last blog I presented the illustration as shown below. In this blog I will focus on the parts of this illustration in which the solution architect / application architect plays a role

 Read more

In my last blog I presented an illustration which shows the two primary aspects of the architects’ role. On one side they play a role in strengthening the heartbeat. On the other side, they play a role in envisioning the future.

The focus in this blog is on the solution architect or application architect. The way the Enterprise architect deals with Scrum will be explored more in detail in a later blog. This blog combined with the previous 3 blogs can be also downloaded as a whitepaper from the Xebia website: http://www.xebia.com/architects_scrum

What is the role of the architect?
Last blog I presented the illustration as shown below. In this blog I will focus on the parts of this illustration in which the solution architect / application architect plays a role

 Read more

In my last post I stated that there is a lot of emphasis on the fact that architects have to help to get the scrum team to work better, faster en with more quality. By following the agile values the architect will help “strengthening the heartbeat” of the scrum teams. However the activities of architects should encompass more. In this blog  I will explain what this is and how to incorporate this in your way of working with scrum teams.

 Read more

In my last post I stated that there is a lot of emphasis on the fact that architects have to help to get the scrum team to work better, faster en with more quality. By following the agile values the architect will help “strengthening the heartbeat” of the scrum teams. However the activities of architects should encompass more. In this blog  I will explain what this is and how to incorporate this in your way of working with scrum teams.

 Read more

This blog is the second of a series of blogs in which I will examine the role of architects in Scrum. Last week I started with the forgotten questions of Scrum. In this blog I will look in more detail to the Agile Manifesto and the agile values.

Architects and the agile values

Most of the literature concerning the role of architects in an agile context focuses on the Agile flow itself and how architects can avoid disturbing that flow. Mike Cohn, in his book “succeeding with agile” makes the distinction between coding & non-coding architects. In where he states that the coding architects will have less trouble finding their new role in de Agile development process.

An architect within a team has to be able to code himself. He is a team member, who has more experience in structuring the application being build compared to other team members.  By using that experience he can add value to the team.  Scrum has no particular role for non-coding architects. The question rises if this is totally true. Read more

This blog is the second of a series of blogs in which I will examine the role of architects in Scrum. Last week I started with the forgotten questions of Scrum. In this blog I will look in more detail to the Agile Manifesto and the agile values.

Architects and the agile values

Most of the literature concerning the role of architects in an agile context focuses on the Agile flow itself and how architects can avoid disturbing that flow. Mike Cohn, in his book “succeeding with agile” makes the distinction between coding & non-coding architects. In where he states that the coding architects will have less trouble finding their new role in de Agile development process.

An architect within a team has to be able to code himself. He is a team member, who has more experience in structuring the application being build compared to other team members.  By using that experience he can add value to the team.  Scrum has no particular role for non-coding architects. The question rises if this is totally true. Read more

This blog is intended to be the first of a series of blogs in which I will examine the role of architects in Scrum. I will start with what I think that are the forgotten questions of Scrum and in next blogs I will examine how the role of the architect changes, what kind of architects are needed and and which activities architects should be doing to be successful and  valuable.

The forgotten questions of  Scrum

In the 1960’s Alfred Chandler already wrote that the organization structure of an organization is tightly related to its strategy and based on its organizational processes.  In the optimal world according to Chandler: Structure follows processes follows strategy. Read more