Skip to Content

Lets start with the definition of the BPX role from the “Your Community Business Process Expert (BPX) Book” wiki at the bpx community: “The BPXer can most simply and accurately be defined as a person with the ability to quickly understand business needs and translate that understanding into a form that leads to the creation and/or composition of better solutions.

Now, I like to ask a few questions and, hopefully, provide some useful input for the role discussion. But I need some more context to phrase my questions…

Some background on roles in building with bricks and mortar…

What is architecture? In a nutshell: it is the combination of usefulness, gracefulness, and firmness. Please take a short look at my blog Architecture, Vitruv and Web 2.0Architecture, Vitruv and Web 2.0Architecture, Vitruv and Web 2.0 to get some ancient background on this topic.

The master builders of the Renaissance

For as long as human beings have existed, they have been building. In the context of this article, however, the age of the Renaissance is of particular interest. This was the glorious age of master builders such as Filippo Brunelleschi (1377 – 1446) and Francesco Di Giorgio (1439 – 1501). The master builder combined the roles of today’s civil engineers and architects. The Renaissance also brought with it a scientific revolution. Leonardo da Vinci (1452 – 1519), Galileo Galilei (1564 – 1642) and Isaac Newton (1642 – 1727) are just a few of those who gave substance to the science of engineering with their mathematical equations.

The Separation of roles: Architect and Engineer

Four hundred years on from the days of Brunelleschi, the fund of knowledge covering all aspects of construction had become too vast for one person, the master builder, to have at his command. And so it was that the year 1818 saw the foundation in London of the Institute of British Architects and the Institute of Civil Engineering. The role of master builder had split into two separate professions with different areas of emphasis: the architect and the civil engineer.














  Engineering perspective   


The engineer adds depth to objective reality. Engineering, which is defined as: “the art of the possible through the creative application of scientific principles … of predicting the behaviour of systems … for the protection of life and prosperity  [after ECPD]. Engineers are very much focused on the things that can be measured and must be controlled through technical structures. They quantitative optimization of a structure, is solely the preserve of the civil engineer; it this which distinguishes him from the architect.    


  architecture perspective   


The architect adds depth to subjective reality. Through the power of human imagination a building can be transformed from material to perceived reality. Objective reality with all its measurable values is endowed by man with subjective attributes such as “beautiful”, “timeless” or “imposing”. The effect of a building on the human observer lies in its combination of form and function. Intensifying this effect is the preserve of the architect, and it is this which distinguishes him from the civil engineer. The very subjectivity of the task is surely one reason for the difficulty inherent in formulating a succinct description of architecture. One thing however is certain: “mankind is the true and final reason for architecture” [FÜH95].    






  load bearing structure   


The load-bearing structure – the interface between architect and civil engineer. The civil engineer and the architect are jointly engaged on the development of a building, yet they approach the task from different perspectives. The architect from a holistic and qualitative perspective, the civil engineer with an eye to detail and quantities. Their meeting point is the load-bearing structure, or system. The load-bearing structure is of central importance both for the material existence of the building and for its perceived reality, as it fulfils a central task in both levels of perspective: (1) Subjective reality: giving form to a building and actively shaping it through areas exposed to view, and (2) objective reality: defining measurements and constructively developing the design to prove its stability. Objective reality is the preserve of the civil engineer, whilst subjective reality is that of the architect.    

Furthermore, Architecture is applied to shape the environment. This requires proper planning of a change within an existing environment. Planning is the development of conceptions with a twofold content: representation of an intended new or changed state (to be state) and the specification of ways and means for effectuating this state (transformation roadmap). The plan must reflect the environment in which the change would take place. In building architecture a house must be embedded within the constraints of a city and its associated regulations and in IT it is the Enterprise with its existing and planned Business strategy, Applications & Technology portfolio, the Organization and IT-Governance. See also my blog About the changing role of IT-Organizations for some background regarding these areas. Last but not least, you could think of the Enterprise Services as the load bearing structure of an IT system.

Is the BPXer a Master Builder?

Lets continue with some more about the BPXer role from the “Your Community Business Process Expert (BPX) Book” wiki at the bpx community: “In the past, duties that the BPXer can execute were performed in part by multiple roles, including business analysts, business architects, business consultants, implementation consultants, IT managers, and process developers to name just a few. Today, the well-rounded BPXer can be expected to possess the ability and talent of any number of the aforementioned roles and thus avoid some of the pitfalls they encountered working in isolation from one another.” Hm, sounds like a lot of talent… I remember talking to Jack Greenfield, a guru in model driven architecture from Microsoft’s VStudio team, some years ago on the parallels of mass customization in the manufacturing industry as a way forward in the software industry and he wrote the bestseller book Software Factories with some of his colleagues. In his publication Mass Customizing Solutions Jack writes: “Unlike other methodologies, however, they also seek to support mass customization by promoting the formation of supply chains.” Thus, providing business solutions needs a very efficient and effective IT solution supply chain, and this in turn requires a series of well known and standardized functions and roles: being dependent on a few people that combine many capabilities, like the master builders in the renaissance, does not scale. So, we should be carefully not to design a role which does not scale to fulfill the demand.

Is the BPXer an Architect?!

I think so, however, that creates a lot of confusion in our IT universe. In my opinion, 70% of the IT folks that have the architect word in their title are… Engineers! They help to get systems firm. Unfortunately, the engineer title is not perceived as very slick on the business card. The other 30% may have the “Enterprise” tag added to their Architecture title and they are… City Planners. Still, they don’t really care for gracefulness, or venustas as Vitruv said. I think that what I see and read at BPX from and about BPXers comes actually closer to my understanding of an architect.



The IT industry is maturing and developing a growing array of roles. The BPX community is an interesting melting pot of capabilities to bridge the gap between technology and business. The BPXer is not a programmer, but has skills to design composites and an eye to joy of use. The BPXer has an understanding to design the right Enterprise Services, but is not an engineer to detail the firmness of the underlying infrastructure. The BPXer is very much focused on the needs of the users and the vision of the business. A few sprinkles of gracefulness and we have a role that Vitruv would have called architect. However, we might just live on with the mixed understanding of engineers and architects in IT and just call the role: BPXer.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Gretchen Lindquist
    I agree with your vision of the BPXer as an IT solution architect, and I think leaving the need for BPX expertise unmet can result in serious ramifications for solution design. I have seen too many poorly designed solutions, where the lack of such business process expertise was betrayed by the inelegance of the design and poor usability of the solution. That is one of my biggest frustrations these days: when told that the solution is “working as designed”, when a solution is impractical and does not meet the business need.



Leave a Reply