Question by Ganesh Ramamurthy
I was hearing Erik Dornenburg of Thought Works in a on-demand InfoQ presentation on "Questions for Enterprise Architect" in which he was discussing about Evolutionary Architecture and was calling out Conformance as one of the issues. We have as many frameworks and standards in place and naturally we always aim to conform to these standards, practices and frameworks and even comply with legal framework. He was considering the case of overseeing the developers to conform to standards as parenting the kids. While it is agreeable that with the fast changing business and technology environment, expecting conformance may be a barrier to innovation, how can we ensure that we produce high quality products. Taking cue from this, I was trying to see if Performance is the answer to the Conformance issue. Your thoughts on this subject is welcome.
The Response
Ganesh, thanks for bringing this topic for discussion and yes, that was a good presentation and is a must watch for all aspiring Enterprise Architects.
Erik in this presentation suggests not to attempt building and enforcing standards and frameworks first and recommends that let these evolve over time in line with the business needs. His comparison of the Enterprise Architect to the City Planner or even latter a Gardener as against the a building architect was very apt.
Getting to your point, he even discusses a case of having the code unit tested by the developers and he highlights how conformance may not solve the problem. With conformance, the teams may just work towards just meeting it and no further. In the same example as he says, if 100% code coverage is required to pass the code move to the next phase, then yes, we may get the results of 100% coverage, but still the unit tests may be incomplete or ineffective in other contexts, like logic tests.
In a broader sense, conformance may be necessary in a highly mechanized or high productivity organization, where it is just the efficiency that matters. But this gives little or no room for doing things effectively and even differently fostering innovation. This is where, depending on the level at which the team operates, the standards or rules should be as open as possible and there must be a feedback loop to review and revisit the standards and rules constantly. Like we have moved from a paradigm of hard coded programming style in the early days of software programming to highly configurable software products, the standards and rules should evolve to a state where they are flexible in adoption for the changing needs.
As Erik also says in his presentation, Architects should refrain from detailing the micro level aspects of the systems and should leave it to the developers. This will go well based on the trust that the architects have on the development team, and that is where the Enterprise Architect has to consider or has a role to play in the Organizational culture and in building the necessary trust with various teams and if this important aspect of trust is missing, then conformance is the one that works better, but not any better than just meeting what was required.
In practice, we see developers with little or no accountability produce inferior code and this is what prompts us to put checks and controls all around and thereby not allowing the developers look beyond what is told to them to do. While just allowing them to do things in their own way is the other extreme, there should be high level norms or guidelines and allow the teams to leverage options without violating the higher level norms. This does not mean that such high level standards or norms should be rigid, and this is where the Enterprise Architect should be receptive to the feedback from all channels and should be more than willing to change these norms as we move on.
It may still be necessary to manage teams at the micro level, but the better way to look at this is about grooming or hand holding the teams to get upto the expected level of performance and then leaving them in a space where they can perform rather than just conforming.
Another way to look at this issue is the way we look at the popular saying "Operation Successful, but patient dead". Wherein conformance expects successful process performance, but it need not produce the desired outcome. So, it is important to measure and focus on the outcome as against the focusing on the conformance to the process.
While the functional or business requirements are written down and signed off, it is the non functional quality attributes of the software products like scalability, performance, maintainability etc where the developers tend to follow diverse practices, resulting in compromise in some such abilities of the systems in the longer term. The Enterprise Architect and in turn the Technical Architect or such other intermediate roles should appropriately interpret and translate the enterprise business strategies into the priorities for these non functional attributes and then let the teams to leverage other artifacts as they deem fit but at the same time not to ignore these priorities.
Yet another related issue which will help address the conformance issue is to have a well defined roles and responsibilities and when authority is delegated to roles, it should be coupled with the constraints attached to such delegation. This will help people perform their roles within the given constraints, leveraging the options they have with them to produce the expected outcomes.
This is a broad topic and applies not only to IT or the development function and this is now increasingly being looked at the enterprise level and even the Boards are expected to perform and not just conform. Change is at the center of everything that we have been talking about and an organization where every member realizes that change is the one thing that is constant we can see Performance as against just Conformance.
I was hearing Erik Dornenburg of Thought Works in a on-demand InfoQ presentation on "Questions for Enterprise Architect" in which he was discussing about Evolutionary Architecture and was calling out Conformance as one of the issues. We have as many frameworks and standards in place and naturally we always aim to conform to these standards, practices and frameworks and even comply with legal framework. He was considering the case of overseeing the developers to conform to standards as parenting the kids. While it is agreeable that with the fast changing business and technology environment, expecting conformance may be a barrier to innovation, how can we ensure that we produce high quality products. Taking cue from this, I was trying to see if Performance is the answer to the Conformance issue. Your thoughts on this subject is welcome.
The Response
Ganesh, thanks for bringing this topic for discussion and yes, that was a good presentation and is a must watch for all aspiring Enterprise Architects.
Erik in this presentation suggests not to attempt building and enforcing standards and frameworks first and recommends that let these evolve over time in line with the business needs. His comparison of the Enterprise Architect to the City Planner or even latter a Gardener as against the a building architect was very apt.
Getting to your point, he even discusses a case of having the code unit tested by the developers and he highlights how conformance may not solve the problem. With conformance, the teams may just work towards just meeting it and no further. In the same example as he says, if 100% code coverage is required to pass the code move to the next phase, then yes, we may get the results of 100% coverage, but still the unit tests may be incomplete or ineffective in other contexts, like logic tests.
In a broader sense, conformance may be necessary in a highly mechanized or high productivity organization, where it is just the efficiency that matters. But this gives little or no room for doing things effectively and even differently fostering innovation. This is where, depending on the level at which the team operates, the standards or rules should be as open as possible and there must be a feedback loop to review and revisit the standards and rules constantly. Like we have moved from a paradigm of hard coded programming style in the early days of software programming to highly configurable software products, the standards and rules should evolve to a state where they are flexible in adoption for the changing needs.
As Erik also says in his presentation, Architects should refrain from detailing the micro level aspects of the systems and should leave it to the developers. This will go well based on the trust that the architects have on the development team, and that is where the Enterprise Architect has to consider or has a role to play in the Organizational culture and in building the necessary trust with various teams and if this important aspect of trust is missing, then conformance is the one that works better, but not any better than just meeting what was required.
In practice, we see developers with little or no accountability produce inferior code and this is what prompts us to put checks and controls all around and thereby not allowing the developers look beyond what is told to them to do. While just allowing them to do things in their own way is the other extreme, there should be high level norms or guidelines and allow the teams to leverage options without violating the higher level norms. This does not mean that such high level standards or norms should be rigid, and this is where the Enterprise Architect should be receptive to the feedback from all channels and should be more than willing to change these norms as we move on.
It may still be necessary to manage teams at the micro level, but the better way to look at this is about grooming or hand holding the teams to get upto the expected level of performance and then leaving them in a space where they can perform rather than just conforming.
Another way to look at this issue is the way we look at the popular saying "Operation Successful, but patient dead". Wherein conformance expects successful process performance, but it need not produce the desired outcome. So, it is important to measure and focus on the outcome as against the focusing on the conformance to the process.
While the functional or business requirements are written down and signed off, it is the non functional quality attributes of the software products like scalability, performance, maintainability etc where the developers tend to follow diverse practices, resulting in compromise in some such abilities of the systems in the longer term. The Enterprise Architect and in turn the Technical Architect or such other intermediate roles should appropriately interpret and translate the enterprise business strategies into the priorities for these non functional attributes and then let the teams to leverage other artifacts as they deem fit but at the same time not to ignore these priorities.
Yet another related issue which will help address the conformance issue is to have a well defined roles and responsibilities and when authority is delegated to roles, it should be coupled with the constraints attached to such delegation. This will help people perform their roles within the given constraints, leveraging the options they have with them to produce the expected outcomes.
This is a broad topic and applies not only to IT or the development function and this is now increasingly being looked at the enterprise level and even the Boards are expected to perform and not just conform. Change is at the center of everything that we have been talking about and an organization where every member realizes that change is the one thing that is constant we can see Performance as against just Conformance.
