Posted by Denis Koelewijn in the early morning: July 15th, 2010
This is the eight post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The eight principle we discuss is called “Focus on the value stream“. (more…)
Posted by Reint Jan Holterman around lunchtime: June 28th, 2010
Virtualization and cloud computing have exploded over the past few years. A recent study shows that 90 percent of businesses have implemented server virtualization at some level and Gartner estimates the current market for cloud services is $46.4 billion and will reach $150.1 billion by 2013. With other estimates saying business applications can be made three to five times less expensive and consumer applications five to ten times cheaper, it’s no wonder it’s taking off.
Among other benefits, virtualization and cloud computing are helping companies remove physical dependencies from network resources, respond faster to changing IT-infrastructure needs, and lower overall costs. While this is all well and good, as companies add more and more virtual resources to their network, they struggle to keep track of them. The reason? Virtual sprawl.
(more…)
Posted by Gero Vermaas in the early evening: June 21st, 2010
This is the seventh post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The seventh principle we discuss is called “Architecture Initiated by Business Goals“. (more…)
Posted by Sander van den Berg around lunchtime: June 11th, 2010
This is the sixth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The sixth principle we discuss applies to the process of architecting and is called “Iterative Architecture Development”.
Posted by Denis Koelewijn at around evening time: June 2nd, 2010
This is the fifth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The fifth principle is called “Just in time, just enough“. The essence of this principle is that only architectural work is done that is necessary and possible at that very moment.
(more…)
Posted by Gero Vermaas in the early morning: May 27th, 2010
This is the forth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The forth principle is call “All hands on deck early on” (initially coined by James O. Coplien). The essence of this principle is that all stakeholders of a project are involved at the start of the project.
Posted by Sander van den Berg in the early evening: May 20th, 2010
This is the third post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive.
The second principle we discuss applies to an important faces of architecting and is called “Think Big, Act Small“. (more…)
Posted by Denis Koelewijn just before lunchtime: May 13th, 2010
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. Last week we discussed the first principle Always involved. In this blog entry we discuss the second principle that applies to the architect role and the architectural artifacts and is called “Travel Light“. Travel light should be taken literally, how much does the architect have to carry around running from stakeholder to stakeholder? How much material does he need to explain the business needs to the development team, what does he need to explain the vision of the product to the business, to involve operations early on, etc., etc. ?
Posted by Erwin van der Koogh just before lunchtime: April 30th, 2010
I was triggered recently by a status update from someone that mentioned that we will have to get ‘this’ right the first time around in the future.
This particular case was about a test, very late in the project cycle, where lots of things needed to get together perfectly to make it work. Any delays would not only delay the current project, but all other projects that rely on the shared resources being used. This huge cost if things go wrong is why it is so imperative that we do get it right the first time around.
The problem is that this involves tens of people across multiple companies and departments, who have written thousands of lines of code.
Now I do not know what they are going to do to make things right in the future, but if we go by past experience most people will want to enforce even stricter entrance criteria.
There are a couple of problems with this approach:
(more…)
Posted by Sander Hautvast mid-morning: April 28th, 2010
What is ‘middleware’? French professor Sacha Krakowiak defines middleware
as [a] software layer [which role] is to make application development easier,
by providing common programming abstractions,
by masking the heterogeneity and the distribution of the underlying hardware and operating systems,
and by hiding low-level programming details
This makes sense, considering the fact that writing an http server nowadays or a servlet-container is not considered sane anymore, given the multitude of commercial and open source products that have already proven themselves. Over the years a range of products and standards has emerged that to a growing extent hide the low-level intricacies and provide the application programmer with easy yet powerful abstractions. They range from webservers, databases and application servers to EBS´s and BPM platforms. They form the IT landscape that enable modern business. And it´s their heterogeneity and distribution that is at the heart of the emerging problems that we will address in a top-10 style series of blogs in the coming weeks.
(more…)