Earlier this year, I was invited to present a talk at Devopsdays Boston about deployment as the new build: how deployments are carried out now, how they will need to adapt in a more virtualized, on-demand application landscape and what fundamental improvements will need to come before deployment matures into the invisible, it just works™ experience build is today.

In the previous post, we compared deployment to another key process in the application lifecycle – build – and asked which key developments turned it from a magical “black box” into the “just works” process it is today.

We identified Reusable commands, Models and Conventions++ as three key steps, which we’ll look into in more detail in this post. Then, we’ll shift back to deployment and ask which improvements will be essential to getting to “just works” here.
Read more →

Authenticating users is an important part of an application. Limiting the access to resources with authorization too. Spring Security is a reference in web environment. However, it is tied to the Spring technology and the size of the library — more than 10 JAR of dependencies — may restrain its use. Moreover, its lack of integration with Guice or the recurrent deployment of an App Engine application may exclude it. This is the opportunity to take a closer look at Apache Shiro.

• Introduction to HTTP Authentication
• Shiro servlet filter
• Secure a resource
• Test integration
• Realm and Matcher for the authentication
• A powerful permission model
• Authorize with annotations
• Shiro, a true challenger

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 →

Recently, I was tweaking MultiSPI to add the following class loading fallback logic:

[java]
if (threadContextLoader != null) {
loadFromContextLoader(className);
} else if (systemLoader != null) {
loadFromSystemLoader(className);
} else {
loadFromBootstrapLoader(className);
}
[/java]

and realized that it’s not immediately evident how to do this in a uniform way. But actually, it’s quite simple…getting a ClassLoader object for the bootstrap loader is just a couple of lines of code.
Read more →

I am a strong believer in the fact that we don’t need Devops. We’ll at least I believe we shouldn’t need Devops. And I’ll tell you why.

Devops is a set of methods and procedures that is geared towards integrating the Operations specialist into the development team. This is done to the ends of developing an integrated software product consisting of the end-users application and related infrastructure components like middleware and operating systems.
Let’s take a closer look.

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 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 →

In Agile, everyone agrees on the concept that continuous improvement is a good thing. In Scrum and also in most Kanban practices we even have a ceremony to support this, namely The Retrospective. This periodically occurring meeting (often every other week) with the entire team plays a vital part in the process and in team dynamics.

In most retrospectives, focus is on improvement. Questions are asked like ‘What is going wrong or could be done better?’, ‘What can we do to improve things?’, ‘Did we actually improve?’. While there is real value in these questions (and they should definitely should be asked), there is another part of a retrospective that is also very important: The Good Things.

Read more →

Over the last 4 month’s we have written a series of blogposts describing 11 principles of Lean Architecture. This post will be the last of the series, the wrap up post.

Read more →