From my rather narrow perspective of technologist, this is a very interesting topic of discussion that transcends the boundaries of a role scope definition, that of business architect, to the very essence of the renewed relation between technology and business practice, on one hand, and the positioning of the technologist and the business people in a charade that is actually more complicated than initially thought, on the other hand.
In nowadays ever changing, many times explosive technological environment, where the value has a depreciation time reduced to tens of months and counting down, the best thing an architect can do most of times is to play catch up. Although the architecture job has been always considered an activity residing in the conceptual sphere of things, and very stable by that, the ever changing technology challenges the validity of the concepts themselves, intrudes into the quiet tower of technology agnostic thinking, and that puts the architects on a very thin ice. In our professional world, the IT concepts do not have the sturdiness and the immortality of those backing up the game of chess for instance, whose rules and basic strategies have not changed for a thousand of years. Especially lately a new technological break-through spawns a new architectural abstraction, with many existing concepts more or less impacted. Let’s take for instance the notion of database, which has been for ages the main pillar of the information systems. For any Information System architect of classical formation, the very essence of the database stays in its controlled structure, which most of the times is covered by the concept of normalization. Tens of years of hard work established into the software engineering community a common set of norms and practices that in general have to be followed by the dot for a sound information architecture to be successful. Plenty of data access services and layers have been built to facilitate the access to this “fair and square” data repositories. Even the exceptions (or should I say extensions?) to the well established model, like data warehouse denormalization, falls back into the pattern through the “star schemas” crystal clear structure, which I would very much place in the same category of “normalized structures.” And now there comes the big challenge: the big data model, which throws in the glove of a very new type of approach. The new approach stipulates that there’s maybe more value in the peripheral, non-structured, non-related data (or “data exhaust fumes”) only if we start drilling into it with the right tools and the right frame of mind. A brilliant success of this new strategy, that of big data, the search engines, are living proof that the technology follows more the laws of nature than the plans of humans: the technological tsunamis destroy old ways of life only to create space for new ways of life, more aligned to the constant craving for progress.
And now I’m coming back to the main topic. Where sits the Business Architect in this new, crazy, maddening world? On a very thin ice, I’d say. Because the business architect is trying to come up with a strategy based on the classic set of chess pieces she knows, that suddenly stopped moving the way they used to: the knight can now move like a horse, the tower jumps like a queen, and guess what, there are new types of pieces on the chessboard that nobody saw before. The technology architects (application, information, infrastructure) breathe hard to keep up the pace, to understand the new sets of chess that the IT giants/promoters keep throwing on the market, while the business architects are more and more tempted to hold back and say: “Ok, fellas, this is technology and I don’t care what breed is. All I care is the entry in and the exit from the system. Knowing those I can re-arrange and refine my business processes. “ And this may be a not so good recipe, because nowadays it’s not about business process B1 uses system entry S1 whose exit S2 provides input for business process B2. Nowadays it could be that the biggest portion of business process B1 ends up engulfed by system S, it transforms the manual work into automatic workflows that render obsolete lots of business activities part of the business process, and could end up by shattering to pieces the business process itself. Only because the technology architecture allows it. Or better said, it imposes it. Why? Because it can.
If I can use another metaphor, the RoboCop is the perfect example where lots of police business processes and activities made by and assigned to people (investigation, analysis, leads, strategy, tactics, etc.) are taken over by a robot, hence a machine, who is part of the force and fills in exactly the job description of a multitude of desk and field officers. Was this something required by the police department business architect? Or spawned by a thoroughly analyzed set of business needs? I very much doubt. But regardless, the business architect is the one to put together the draft of the renewed business processes, tasks and activities that are going to use RoboCop, only that in a 6-months range, a new version of this robot is going to be released thanks to the technology architects, only because the technology did some serious inroad, not because there are new business needs. Although with new technical features come new business needs (I thought the direction was reversed?) All that the business architect can do is to quickly move along and come up with business needs for the new state of the art artifact. And to do that, he should have a good understanding of the new RoboCop set of features, which will become more complex from year to year, like any new digital camera that comes on the market. But can he? Is her formation wide enough to allow her to extract business needs from a deep introspection into the new technical capabilities? And is it fair, after all? The initial job description seems to be now totally upside down.
