Home | Login | Recent Changes | Search | All Pages | Help

ArchitecturalImprovements

Everyone wants faster, cheaper and better systems, but how do we make our case to the business to get the time, money or support we need to put infrastructure in place for stable adaptable architectures?

What are your experiences?

-BeckyWinant 2003.06.02

Good lord, a business / technical question. What are you, nuts?

-- JimBullock 2003.06.02

I'm not sure what you mean by infrastructure. ExtremeProgramming recommends evolving the infrastructure (via refactoring) as part of the normal cost of implementing features...

KeithRay 2003.06.02

• SCM and automated builds to support near-instant build turnaround and collective ownership.
• Sufficiently consistent tool configuration on each team member's machine to produce consistent builds and tests.
• Repository backups.
• DBMS micro environments for testability and images for acceptance testing practice runs.
• Production operational support organization(s) for post-delivery success.

--BobLee 2003.06.02

BeckyWinant 2002.06.03

An opinion? Moi? Well, I'll try, but it's a stretch. Actually, I'm thinking a bit first. Try not to faint from the shock.

Are you on a timeline here, or can I ruminate some? - JimBullock, 2003.06.03 (The spontaneous zingers actually aren't all that spontaneous sometimes . . . )

What the motivation to provide the value?

How do you advise people how to be able to provide that value?

Inquiring minds are, well, inquiring... BeckyWinant 2003.06.03

Fear of changing legacy code is healthy, if the legacy code is not fully covered by automated tests. You need something to rapidly tell you if you've broken something when you're doing a code improvement. Micheal Feathers is working on a book about making legacy testable here: http://groups.yahoo.com/group/welc/

Probably a good motivator for improving code is measuring the cost of changing code for bug-fixes and feature additions (and measuring the FaultFeedbackRatio). The older and cruftier the code is, the higher the cost of changing it.

Perhaps the best way of addresssing fear of refactoring is by practicing it on toy projects. William C. Wake has a book called The Refactoring Workbook due in July. Preview chapters are on-line:

The other key about refactoring to improve the design is to take small steps. For example, most code has functions / methods that are too long, multiple 'bundles' of lines, sometimes with comments describing the intent of each bundle. Use the "extract method" refactoring to move each little bundle of lines into a new function, named after that comment. See ExtractMethodExample. When big methods have been broken down into small methods, duplicate code becomes more obvious, and can be removed, reducing the amount of code to be maintained and raising the level of abstraction in the code.

Big refactorings are much easier if lots of small refactorings have already been done. It is important that the team members agree on the value of the small refactorings - you don't want inviduals to 'undo' each other's code improvements.

KeithRay 2003.06.04

Many companies who have grown through acquisition or even maybe "one project at a time" responding to local department needs have a large collection of applications that are redundant and not very efficient. As time marches on both start to hurt.

How does refactoring get done in large organizations with those large overlapping applications where it is difficult to actually understand exactly what each systems does? Streamlining system by system doesn't seem to be able to spot the inconsistencies and overlaps across applications. Have you done this?

BeckyWinant 2003.06.04

re - large orgs resulting from mergers. I thought in most cases the dominant personalities in management just junked the software from the others. ;-)

I don't have any advice on overlaps across large systems. Maintaining and refactoring a large application is often safer than trying to replace it from scrach because of the lost reqirements problem. I don't have experience in trying to merge redudant large systems.

KeithRay 2003.06.03

The merger is an "all bets are off" requirements change.

BobLee 2003.06.05

You are right-on regarding requirements changes. The presuppositions that built each system were very different requirements and even different business environments. (Lets not even introduce different vocabularies!).

It is ugly, and it is a very costly problem for companies who have been acquisitive and hoped to blend and absorb. Not that easy and quite a challenge to adapt systems in faster cycle times to meet market demands and needs.

-BeckyWinant 2003.06.06

Would it were so easy that the one party could preside!

Business is not always that simple. Sometimes a company acquires another company in a related market. For the acquiring company this is good because they have potentially enlarged their market or market share.

From a systems view the acquired company's software can't necessarily be junked. Take the case of any regulated industry: DoD, FCC, FDA( Food and drug), financial, insurance and so on. You, the mother company, produce heart monitors. The company you acquire makes equipment that monitors blood sugar for diabetics. Are the regulatatory rules the same? Probably not. Can cthe mother company afford to lose the compliance logic in the acquired company's systems? No!

A n d . . . there will be conflicts and overlaps in the things that are the same. What is the word that the mother company uses for "patient"? Is it tha same as the diabeties product company's? What sorts of information characterizes a patient? Is that the same from company to company? I'm sure you can imagine where this line of reasoning continues.

Another challenge is formatting variance. This is more easily addressed through refactoring techniques.

All of it is an interesting challenge for architects.

BeckyWinant 2003.06.06

This one has some power words in it: "make our case", "infrastructure", "stable", "adaptable", and "architectures." There are at least these considerations:

- Point solutions are locally owned. General solutions are shared, creating a "commons" problem. "Adaptable" may matter to the guy who's needs aren't served yet, but doesn't matter to the guy who's needs are met. Avoiding the commons lets the latter avoid risk.

- So "shared" payoffs have to be addressed where the shared expense is accounted for. All IT, vs. department level, for example. In principle, several departments or teams could band together to do and fund a shared kind of thing, to their mutual advantage. I have seen this work - but infrequently. And the coalition has to get sponsorship up on the org chart, where all their budgets meet.

- Providers of solutions often are reluctant to "improve" the situation. You get promoted by building a staff which you can do by having a steady series of small problems. The guy who needs an assistant gets a promotion. The guy who works himself out of a job may get an "atta boy", and may get fired as well. What's the better career move?

- So the organization has to reward _work and cost avoided_, and also _opportunities enabled_. These are real hard to quantify.

- Lots of "shared" solutions implemented in the architecture space don't pay off. Sometimes it's a bad solution. Sometimes the keepers of the shared resources appoint themselves gatekeepers of progress.

- The keepers of shared solutions hold a policy for the organization, but are not the ones who make the policy.

The phrase that comes to my mind for making the case is: "that business" as in "let's get out of that business", and "do we want to be in the that business?" Follow that conversation with: "How do we go about being in that business well?" or "How do we get out of that business?"

For example, there is a whole lot more flexibility in a generic reporting tool than in a whole lot of hard-coded reports. Cheaper too. But, there will be a bit less flexibility in the output, the users will have to learn something different, and it's possible to select, deploy, or operate a perfectly good general reporting tool in such a way that it fails dismally. So: "Do we want to be in the 'writing hard coded reports' business?"

I have also had some success with introducing support costs, and the word "proliferation" as in: It takes one FTE to stay up to speed on Granking. We do Granking three different ways right now. If we can make ourselves a generic Granking service that every app can use, we end up with a smaller keeping up problem, and deeper understanding of Granking. We may even get to use our generic Granking capability with the next thing we do. But, we'll have to agree on a generic Granking service, and the three Granking users will have to cooperate in using this service.

The move toward a more "flexible architecture" seems to work best when there is an existing problem. Then you couch the solution in terms of solving the current problem, and creating a resource for other similar uses later. Blank page architecture has become a theoretical exercise every time I have seen it, delivering nothing, or sometimes small amounts of very crappy stuff.

The question as asked is pretty abstract. How else should we talk about this? -- JimBullock, 2003.06.11

Yes, this is abstract. And policy makers and owners are more to the point than technology.

OK, I'd be interested in stories of finding "the real problem" then creating change in a risk-adverse system or in a large system where "movin the ship" is a slow and steady process.

- BeckyWinant 2003.06.11