Friday, April 30, 2010
The architecture group is responsible for ensuring that no work is duplicated, that the company aligns with the standards and that the best technology practices are followed.
Think of the architecture team as the “special forces” team made up of senior technical advisors who maintain a holistic picture of the entire technical environment, both present and future.
When empowering the architecture team it wise to keep an eye out for those headstrong individuals who, in their quest for architecture purity, or because of ego, tend to push their own point of view or technical religion, rather than addressing customer needs. A good architect should be an expert and, by definition, an expert is someone who can solve any given problem in multiple ways. If you encounter an architect continuously hammering home the same solution to every problem; all the while blindly refusing to consider any other alternative, then it’s time for you provide some serious direction.
While the architecture team should enforce the standards, it should also demonstrate flexibility in adjusting and enhancing these standards on an on-going basis. The way to do so is by staying in tune with the business requirements and with the system analysts, engineers, and developers who are responsible for delivering the solution.
This is what happens. You form a small group of bright, technical people with the objective of having them develop the framework, tenets and standards needed by the organization. However, if this group is not given the responsibility to actually deliver specific components, it becomes very easy for them to move to the realm of platonic but impractical beauty. In this realm, all architecture constructs are conceptually beautiful and theoretically comprehensive, but essentially non-workable and non-functional (the original Open System Interconnection developed in the eighties comes to mind). Should the situation be allowed to fester, you will soon hear your programmers mocking these “fools on the hill” whose only ability is to produce extremely abstract architecture papers that will never be followed through. Meanwhile, the very talented architecture team will grow increasingly frustrated as they watch the fruit of their work ignored by these “spaghetti-code hackers”. I don’t have to tell you that this is not a healthy and productive state of affairs.
Giving architects a degree of development responsibility sends them a message that they will not be able to get by simply by publishing a series of holistically irrefutable, enterprise architecture bibles. Instead, the architecture group should be tasked with delivering something, as in actually coding stuff!. This approach is to prevent the emergence of what author Joel Spolsky calls, “Architecture Astronauts”, or what they were called in my day, “Blue Sky Architects”.
Accordingly, while the architecture group should have clear governance in defining and directing the standards, they should also be tasked with delivering code. To keep this team well grounded, a good assignment would be to give them responsibility for the development of system framework services, libraries, and toolkits.
Alternatively, line development functions should have a seat at the table in the development of technology standards. The architecture team has the overall responsibility of organizing and running technology forums that ensure that the technical team has a say in the process. These forums should allow everyone in the development community to speak their mind and to give their personal viewpoints regarding standards and tenets.
Still, at times, some line developers will need to be reigned over simply because it is not feasible to pursue the whims and wishes of those whose motivation might be to pursue “cool-hacks” rather than to ensure the long-lasting services of his or her deliverable. In the end, however, it is always more advantageous to bring these discussions to the forefront and to address them openly rather than behaving in a “dictatorial” manner.
I have found that when the architecture group does their work correctly and involves the entire development team, they will emerge as the natural leaders. The best case is when line programmers actually seek the advice and help from the architecture group. When you see this happening, you’ll know you are on the right track.
Friday, April 23, 2010
The control center for the transformation project is driven by a Product Management Team or PMT (a “product” in this context, need not be something your company will necessarily sell to the outside world. A product can be any specific project deliverable). The PMT should be the official technology touch point for business requests and should have the ability to refine those requests via use of business analysis processes, estimate the cost of the effort, and prioritize the potential work versus other commitments. Obviously, the product management team needs to work in line with the architecture and development teams in order to articulate the appropriate response to the requirements.
Having product management to also help with administer the project plans will provide this team with the needed visibility to assess urgent tactical requests. Items to consider for tactical requests are:
1. Is the request simple enough for the tactical group to handle? In other words, the request should not divert resources from the transformation project.
2. If the request is somewhat complex and the tactical group will institute a stop-gap solution, how will the transformation team ensure that the requested feature or functionality will be present in the strategic deliverable?
3. If the request is fairly complex and delivering under the legacy scheme is not cost-effective, how should the request be handled vis-à-vis the transformation activity? In this case, negotiations with the business group should prioritize the request against other expected transformation deliverables as well as assessing the impact on the transformation plan.
Notice that I have resisted using the more traditional term “Project Management Office” (PMO) to refer to this group. I believe this term and governance have emerged from a perspective where project management can be performed by anyone who’s “smart enough”, regardless of specific subject matter expertise. Take for instance the popular “Apprentice” TV Show in which Donald Trump assigns the contestants to “project manage” an activity challenge and then fires the person who, in his opinion, has performed the assignment least effectively. Perhaps this concept works for TV shows, but in the real world of software and systems development the manager responsible for the project had better be someone who understands the technology and has an understanding of the team skills involved in the project. The manager of an IT transformation project cannot have only an administrative function.
I recommend that the actual management of a deliverable be assigned to the appropriate technology manager and not to a generic “project manager”. Instead, the Product Management Team should be seen as the facilitator and enabler for the actual project work conducted by a solution delivery manager. The PMT can have a direct role in specific project related activities: Business Analysis, Project justification and Initiation, Project Planning, Project Tracking, Vendor Relationship Management, Quality Assurance, Implementation and Migration Planning, etc. and should act as a coordinating umbrella for a Project Management Steering Board that includes representation from all other constituencies as well: development, business, finance and operations.
Speaking in practical terms, a key area of friction to watch out for from this team is in delineating a clear line of responsibility for the person who will ultimately be accountable for a project deliverable. The reasons I advise against using the term “Project Management” for this role are: The term “Project Management” naturally implies this entity is responsible for managing the project and thus ultimately empowered to make project-level decisions. If in fact, this group is managing the project then there is no issue, but what often occurs is that the actual project execution is driven by the Development Manager. The term “Project Management” obscures the line of responsibility and causes confusion and tension. Secondly the term “Project Management” does not properly encompass the other areas of responsibility that this function should have: business requirement gathering, lifecycle administration, project communications and tracking, assisting in defining the overall product delivery strategy and ultimately enabling the project delivery.
From an organizational viewpoint, the project coordinator attached to a specific project should have a dual reporting line to the actual delivery manager as well as to the product manager director. The interaction with the former should be both daily and intense since it relates to the minute-by-minute project activities, while the later should only be on a periodic basis for overall status reporting and to receive overall direction regarding project tracking standards and processes. Yes, the reporting of the status may “blow the whistle” on project issues that require the Product Manager to validate the actual health of the project with the Delivery Manager. This should occur in the spirit of “check-and-balances” and should not be seen as empowering the Product Manager with actual supervisory or executive authority over the development team. In any case, there should be proper procedures that allow any conflict between the Product Manager and the Delivery Manager to be escalated to their respective managers for resolution.
No one ever said life wasn’t complicated!
Friday, April 16, 2010
Moving to a transformative environment, SOA requires the establishment of governance and competencies adapted to handling the specific features of this emerging technology framework. Gone are the days of purely hierarchical structures with their military style command lines. SOA requires a comprehensive, holistic management approach. Indeed, transformation management requires the understanding that there are a variety of ways to view and control a project.
Just as with the proverbial elephant that is felt by a group of blind individuals (some touch the legs and “feel” a tree trunk, others the ears, and sense a flag, and so on) the system will appear differently to the various constituencies. The engineering teams will focus on the physical elements of the solution: access technologies, networking and the central computers. The business partners will be more concerned with the views of Clients and Services including the manner in which information is presented, processed, and consumed. Software developers will see specific service implementations along a 3-tier Model View Controller (MVC) paradigms; while enterprise architects and project managers will want to maintain the “whole image”; becoming the guardians of the holistic view of the system.
It is important to note that there is a time dimension as well. The optimum structure for execution is not necessarily the ideal way to structure the ongoing support of the deployed system. Ideally, the structure to execute the transformation should be one that gradually morphs into an organization that is capable of maintaining and supporting the new system on a steady-state basis.
The challenge is made more complex by the fact that business-as-usual operations must be maintained, even as the transformation is being executed. This means you will need to accept the existence of a dual organization structure for the required transitional period: the organization needed to support the legacy environment and the one executing the transformation.
The question is how to gradually sunset the skills, while ramping-up the new organization needed to support the future end-state. Most important is how to do so with regard to the issues presented by people considerations. People are not replaceable machines, and the transition from legacy to new will require a carefully crafted staffing plan that encompasses retraining, reorganization and evaluation areas.
It’s always disconcerting to mix the “old” with the “new”. The feeling is just like the one I had this morning when I accidentally used toothpaste as shaving cream. Blame the shape of those new toothpaste containers, though I have to admit the mint in the toothpaste gave me a curiously refreshing shave (completely unlike the nasty feeling one gets when confusing hemorrhoid cream with toothpaste!).
There is no escaping the reality that for a period of time, you will need to handle a mixture of “old” and “new”: old processes running in parallel with new processes, long tenured people not yet fully trained in the new dealing with younger staff not yet knowledgeable about the existing processes, senior staff versant in the “old ways” working with newer staff unacquainted with the cultural traditions, and so on. This is not an easy task. We all know that dual organizations are usually a recipe for conflict and duplication. You should therefore make certain that the specific governance and responsibilities during this messy period of transition are clear and agreed to by all concerned.
If there is a new tactical requirement, should you give it to the legacy team to “patch” the legacy system, even if in the long run the solution might be a throw-away? Or should you try to develop a hybrid solution that can be expanded to fit the strategic standards?
In the end, as leader of the effort, you will need to broker the assignments of emergent work so that new work takes place in the right sphere. In general, the easiest way to scope responsibilities is to task the legacy team with maintaining daily operations and service levels and get the transformation team to fix its sights on the new deliverables. The problem occurs when new urgent requirements demand shifting the focus away from the end state delivery. New requirements must be handled only when truly urgent and necessary and must be the domain of the legacy group only on an exception basis. At the start of the transformation, you will need to agree with the line of business as to the manner in which you will jointly handle tactical requirements, and the thresholds that must be crossed in order to trigger urgent and necessary changes to the legacy environment.
IT Transformation efforts require the involvement of other groups in the company other than technology. This means the business, finance, legal and general operations teams all need to be involved at some point. However, there are three specific groups whose roles you need to make certain are in place from the very start: Product Management, Architecture and the SOA Team. More on each of these three teams next.
Friday, April 9, 2010
There are all kinds of books dealing with IT management techniques and the many methodologies that have evolved since the start of modern day computing. However, at its core, IT management is still an art; not a science. In fact, while the use of structured methodologies can be helpful in the context of specific project tracking, it should not be relied upon as the panacea that ensures the success of the project. Fact is that, oftentimes, processes and methods are applied only to satisfy the control instincts of bureaucracies and, applied dogmatically, can do more harm than good by getting in the way of the actual project execution.
But if strictly following “management” methodologies (mythologies would be a more proper name!) is not particularly useful, then what? Well, it’s not that techniques should not be applied. It’s that the techniques that should be applied are those that result from intuitive management assessments adjusted to the specific conditions of a given project. That is, IT projects tend to have so many variables that effective management of the project should be tailored specifically to that project. There’s a reason why project management is not done by robots. You can’t run projects, especially major projects, with fixed “how-to” type instructions written by a management consultant guru in a book intended for the masses and expect success. The name of the game is intuitive flexibility and best practices. It’s about guidelines; not law. It’s about common sense; not blindly following administrative dictums.
Project success is also about focus. A common belief is that Magellan was the first explorer to circumnavigate the world. Fact is that, while Ferdinand Magellan was indeed the captain of the expedition launched to go around the world in 1519, he never made it around the world. Instead of keeping his eyes on the goal of reaching the Moluccan Islands (Indonesia) by going west and then returning via the east, he allowed himself to get distracted and became embroiled in local native politics. He was killed in a battle between Philippine tribes. Leaderless, only 18 severely ill and famished men out of the 237 men who set sail in five ships to circumnavigate the globe, made it back alive to Spain.
The typical transformation project takes longer than 24 months to complete (a shorter project time span would suggest you are not actually undertaking a transformation but rather a renovation; a quick-fix). Now, the average stay time for a CIO is 24 months. Do the math. No matter in what space-time continuum you happen to live, the expected project length vis-à-vis the average CIO tenure presents an inescapable conundrum: typically, the management team completing the project (if the project is completed at all!) will be different from the team who began it.
Indeed, the single most important cause of project failure is the fact that the sponsorship team is no longer around when the project finally gets going. Once the new team is handed the reins, they often feel obliged to pooh-pooh the work done by their predecessors. Anything that occurred prior to their arrival must be wrong. Otherwise, why would they be taking over except to fix the mess?
It doesn’t matter; you could either spend the time of your tenure as an IT executive twiddling your thumbs or start planning for some sensible deliverables. Choose the latter. In the end, even if you don’t complete the project yourself, having a successor complete the project successfully is something you can proudly note in your résumé. Similarly, if you are part of the new team, it is still in your best interest to leverage all prior “rights” and to “right” all prior “wrongs”.
Next I’ll cover the management approaches that are pragmatically helpful, whether you are starting a transformation project or are in the process of fixing “other people’s” messes.
And so, we will now shift away from the technical aspects of IT Transformation and move into the equally complex management issues of transformation. Beginning with governance and organization . . .
 “Common sense is not a single thing. Instead, it is an immense society of hard-earned practical ideas—of multitudes of life-learned rules and exceptions, dispositions and tendencies, balances and checks.”—Marvin Minsky
Friday, April 2, 2010
“Doctor,” the patient says, “When I press on my calf with my finger, it hurts…”
“I see,” the doctor replies.
“And then when I press my finger on my thighs, it hurts too!”
“Really?” The doctor mutters skeptically.
“I tell you doctor, I must have something serious because it also hurts whenever I poke my arms, my chest and my neck! It hurts all over!”
“Have you considered,” the doctor asks, “that it might be your finger that’s broken?”
Establishment of a control layer will give you access to the needed sync points from which to control the parameters affecting the dynamics of the system. The SOA Fabric (which includes the human element!) will have to react to the conditions you’ve set in these message headers. In the end, while the management infrastructure is there to provide you with real time snapshots of the system, it will be up to you and your staff to properly diagnose the problems that do arise.
Having an SOA Fabric, a Control Layer, and a Centralized Logger gives you the opportunity to view and manage the SOA system in the same grandiose manner as Captain Kirk on the bridge of the Starship Enterprise. The point being that part of the early transformation plans should include the design and development of a centralized dashboard capability for management of the SOA system. Attempting to run an SOA system without a dashboard that offers you a 360 degree on-demand view of all the elements of your system is not unlike Slade—the blind man in “Scent of a Woman”—driving a Ferrari at high speed on the streets of the city. (Now, as the doctor in my story shows, you’ll need to make sure your dashboard system is not broken and that it properly detects and diagnoses what’s wrong with the system and not what’s wrong with itself!)
The Dashboards would not be possible without a Central Logging Server and the placement of event triggers that can drive the dashboard displays. This server must be part of your initial system design and should be treated the same the same as you would any other database for business analytic purposes. To the extent that you capture logged data over time and obtain detailed analysis of your system dynamics (resource utilization versus performance/failures), you will also develop the capability to pro-actively plan the future evolution of your system and to better understand the thresholds that might trigger failures under stress conditions.
Needless, to say, logging and monitoring should minimize interference with the actual operation of the system as much as possible. Logging should always be conducted on an off-band basis. This means that all logging events should be sent to the Central Logging Server on an asynchronous basis. Do you want to log an entire message? Copy it and log the copy, but do not make the production messages flow through the logging logic. In other words, you should duplicate the message containing the logging information and send it to the log server without increasing the latency of the main message flow.
You should be able to run reports against the various logs in the database to proactively identify deficiencies and trends requiring attention. Ideally, you will extract and backup the appropriate summaries and all the logs that you are mandated to preserve for business or legal compliances reasons.
I for one don’t believe you need to make this Central Logging Server a fault-tolerant element in the system, but you should certainly make certain it receives the appropriate amount of attention to ensure its high reliability.
Clearly, the entire area of system management for SOA is very complex and I have just scratched its surface. The key message to keep in mind is that managing SOA is not the same as managing traditional legacy environments. You will need new tools, new methodologies, new processes and prayers to new gods to make it all work!