A little over two years ago I was afforded the opportunity to embrace an agile transformation. I suspect my experience shares parallels with others' agile transformations, particularly when I say that the road was bumpy. One of the recurring bumps was the role that architecture plays in an agile environment - an environment where delivery teams increasingly focus on the present and embrace the uncertainty of the future.
I've recently been reading a classic software book for the first time. That book is none other than The Mythical Man Month. The first few chapters reveal some great insights in the areas I was expecting. More interestingly though, it lends some fantastic perspective in at least one completely unexpected area - architecture.
For years now I have struggled to understand the role of the architect. I've worked with many, all with the same job title, but many with different "day to day titles". Those have ranged from application architect, delivery architect, enterprise architect, security architect, to most recently, user experience architect. Sometimes while working with the great people in these roles, we clashed. I think I always knew why in the back of my mind, but the reason has become much more clear recently. Put simply, decision boundaries were not, and are not clear.
Fred Brooks says that the most important aspect of system design is conceptual integrity. Conceptual integrity simplified is the relative ease of use of a system on a 'functionality offered' basis. Increasing the functions offered by a system increases its complexity. In fact, he says that complexity can increase beyond expectations because "the things one wants to do often requires involuted and unexpected combinations of the basic facilities." Said more simply, functions must be combined to achieve desired behavior. The point that Brooks arrives at is that "ease of use, then, dictates unity of design, conceptual integrity." Ease of use is paramount in system design. Ease of use is the primary responsibility of architecture. He elaborates, writing that, "The architect of a system, like the architect of a building, is the user's agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user."
Where I have struggled with decision boundaries the lines between the what and the how are blurred. Brooks clearly highlights the need for distinct separation between architecture - the what, and implementation - the how. A clear example with a clock is laid out in the book. The architecture of a clock consists of the clock face and the hands. Once a person learns this architecture, he can read the time from a church tower or a wristwatch equally easily. The implementation, however, is invisible to the user. It's everything behind the scenes that results in the user's collective experience. But again, the conceptual integrity is paramount. Consistency and the ability to uniformly interpret the design must be the highest priority.
Several months ago I had a light bulb moment. It's really an unremarkable thought, but for me it was powerful. Every architect should be a user experience architect. Their mandate should be to create the ideal user experience. I believe that is what Brooks is really saying.
Systems today are very complex. More and more users want to combine functions from disparate systems to achieve greater efficiency and insights. Where users desire combined functions, design integrity presents serious challenges. Architects need to be out in front of these challenges designing the combined experience, and making sure it happens that way. That's not the role I see most architects playing today. Their focus is far more on implementation and lower level design. And I think the reason for that is that architecture has become the "next logical step" for the talented implementer. But what does the talented implementer excel at and enjoy? And what does she focus on? Boom, conflict.
In the world that Brooks describes in The Mythical Man Month architecture often requires fundamentally different sets of skills, and some collaborative overlap with implementation. Granted, the role of the architect varies wildly based on the product. For example, a user experience architect for a web-based fitness system might ideally be someone interested in fitness with expertise in web technologies and web design. On the other hand, a user experience architect for a set of APIs for use by developers is likely far more technical, and would undoubtedly he himself be a seasoned developer.
Architecture and development require a rethink and a lot of clarification. Blurring the lines between the two creates role conflict. There are certainly cases where the lines are blurred and collaborative efforts between the roles result in excellent outcomes. Even so, we must ask ourselves if we have properly separated architecture and implementation responsibilities. Because if our architects are focusing on implementation, are we focusing enough on the user experience? We must ensure we have the right focus on the overall user experience. Conceptual integrity is paramount.
I've recently been reading a classic software book for the first time. That book is none other than The Mythical Man Month. The first few chapters reveal some great insights in the areas I was expecting. More interestingly though, it lends some fantastic perspective in at least one completely unexpected area - architecture.
For years now I have struggled to understand the role of the architect. I've worked with many, all with the same job title, but many with different "day to day titles". Those have ranged from application architect, delivery architect, enterprise architect, security architect, to most recently, user experience architect. Sometimes while working with the great people in these roles, we clashed. I think I always knew why in the back of my mind, but the reason has become much more clear recently. Put simply, decision boundaries were not, and are not clear.
Fred Brooks says that the most important aspect of system design is conceptual integrity. Conceptual integrity simplified is the relative ease of use of a system on a 'functionality offered' basis. Increasing the functions offered by a system increases its complexity. In fact, he says that complexity can increase beyond expectations because "the things one wants to do often requires involuted and unexpected combinations of the basic facilities." Said more simply, functions must be combined to achieve desired behavior. The point that Brooks arrives at is that "ease of use, then, dictates unity of design, conceptual integrity." Ease of use is paramount in system design. Ease of use is the primary responsibility of architecture. He elaborates, writing that, "The architect of a system, like the architect of a building, is the user's agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user."
Where I have struggled with decision boundaries the lines between the what and the how are blurred. Brooks clearly highlights the need for distinct separation between architecture - the what, and implementation - the how. A clear example with a clock is laid out in the book. The architecture of a clock consists of the clock face and the hands. Once a person learns this architecture, he can read the time from a church tower or a wristwatch equally easily. The implementation, however, is invisible to the user. It's everything behind the scenes that results in the user's collective experience. But again, the conceptual integrity is paramount. Consistency and the ability to uniformly interpret the design must be the highest priority.
Several months ago I had a light bulb moment. It's really an unremarkable thought, but for me it was powerful. Every architect should be a user experience architect. Their mandate should be to create the ideal user experience. I believe that is what Brooks is really saying.
Systems today are very complex. More and more users want to combine functions from disparate systems to achieve greater efficiency and insights. Where users desire combined functions, design integrity presents serious challenges. Architects need to be out in front of these challenges designing the combined experience, and making sure it happens that way. That's not the role I see most architects playing today. Their focus is far more on implementation and lower level design. And I think the reason for that is that architecture has become the "next logical step" for the talented implementer. But what does the talented implementer excel at and enjoy? And what does she focus on? Boom, conflict.
In the world that Brooks describes in The Mythical Man Month architecture often requires fundamentally different sets of skills, and some collaborative overlap with implementation. Granted, the role of the architect varies wildly based on the product. For example, a user experience architect for a web-based fitness system might ideally be someone interested in fitness with expertise in web technologies and web design. On the other hand, a user experience architect for a set of APIs for use by developers is likely far more technical, and would undoubtedly he himself be a seasoned developer.
Architecture and development require a rethink and a lot of clarification. Blurring the lines between the two creates role conflict. There are certainly cases where the lines are blurred and collaborative efforts between the roles result in excellent outcomes. Even so, we must ask ourselves if we have properly separated architecture and implementation responsibilities. Because if our architects are focusing on implementation, are we focusing enough on the user experience? We must ensure we have the right focus on the overall user experience. Conceptual integrity is paramount.
