In a previous post regarding the emergence of the Business Engineer, I discussed the Who, What and Why of this new type of human capital. At Mendix, we see them growing in numbers, most likely due to the nature of our software. If you’re going to give business analysts the ability to develop software, or developers the ability to communicate business – you’re going to see doors open and walls collapse on either side of the business-IT equation.

The BA

In order to figure out exactly where BE’s come from, so that we can harness their powers for the greater good of business agility, we’ll have to know more about their closest relative – the BA. According to The International Institute of Business Analysis, the role of a business analyst involves: “the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization and to recommend solutions that enable the organization to achieve its goals.”

Well isn’t that something. All of those tasks and techniques are funneled down into a recommended solution and passed along to the technical wizards who turn requirements into reality. I’ve always wondered whether the less-than-technical BAs wish they could, perhaps just once, finish the job and deploy an application. Perhaps they’d hate to deal with code, I’m not sure. What I am sure of, however, is that business engineers dream about models (business-models, pervert!) and how great it would be if they could get requirements and deliver solutions, on their own.

The BE

Call it selfish; call it futuristic; you can even call it a pie in the sky. With the emergence of the business engineer, demand for agile software development, visual modeling tools and a revamped SDLC is truly explosive. Based on the definition above, the BE is not really related at all to who we now know as the business analyst. Though I mean not to offend nor aggravate business analysts or software developers, I must assume that they see the astronomies of their value propositions colliding.

So then, if the business analyst recommends a solution, it must be the business engineer who implements it. And if the business analyst plans the solution, the business engineer deploys it. I may even go as far as to say that business analysts identify the problem, where business engineers solve it. This fine, yet drastic and seemingly impossible, line – is growing in organizations everywhere.

What’s Next

As I mentioned in part one of this series of posts, the ambiguity of the business engineer is becoming more believable with every Mendix user. What was once called impossible by technologists is now championed as magic by audiences of our ‘proof’ of concepts, and we’re betting will one day be considered the norm in enterprise software development. In the meantime, collaboration between business and IT may remain segregated by occupational obstacles inherent to aging technologies and ancient practices.

The current generation of business and technology students is likely to pave the way for career paths in business engineering. Courses in business engineering will be taught by today’s business engineers, and until then, these heroes of enterprise software can only enlighten their organizations with a glimpse into the future of business agility.