Support OzOriginal

Home Guerrilla IT architecture Techniques
Guerrilla IT Architecture definition
Print E-mail
Written by Benjamin Lvovsky   

In short

Guerrilla IT Architecture (GA) is a is a flexible, unconventional, low cost method of reaching business goals. GA approaches a project as a whole including team dynamics, business strategy, IT Architecture. In addition to IT Architecture a solution often comprises fixing team dynamics, cross teams collaboration, use of management and client’s resources.

Focus

 

  1. Team dynamics including group influence, individual behavior, intergroup conflict reduction, group cohesion

  2. Decision making process analysis and its correction

  3. Existing IT skills analysis and possible gap filling

  4. Existing IT Architecture

  5. Client analysis and involvement

  6. Business strategy for sustainable business transformation

You can say “there is no much of an architecture for another architecture approach”. IT Architecture is an activity carrying out tasks at early stages of a project, while the main focus of GA is a holistic approach to the business problem getting the best of current conditions and environment to reach business goals optimal way.

Business requires Solution Architecture plus Team Dynamics plus Business Strategy approached as atomic unit. This changes the traditional role of IT architect from the one who “defines” the higher-level technology and design, to a multi role player. IT Architecture skills needed to be complemented with understanding in team dynamics field, business analysis, organisational structure, business strategy, organizational culture and challenges they present. Only then it becomes possible to find a right IT Architecture to meld into a customised well suited maintainable business solution.

As a result IT Architect’s role in GA gets extended and, good or bad, requires more diverse skills and broader experience for one person to comprehend the solution as a whole.

I called this “Guerrilla IT Architecture”, however it is as much about IT Architecture as other above mentioned disciplines. There is one common thing throughout all the disciplines it employs though - all have IT specifics and details, those small things in IT solutions that are often overlooked causing serious problems later on. And the devil is in details.

Techniques and patterns

Here I put a number of techniques and repeatable patterns I found working through a number of projects in the past from my and others experiences.

1. Background analysis

It is important to analyse a requested solution background in detail. It not just “good to have” for clues for an IT solution but rather a major point of research to start with. Going back to old  cases I see how it would be simpler and cheaper in terms of time, energy and money to pay more attention to the background and history of the problem. It gives answers and facilitates for further steps.

2. Specifics and possible complexities

Every case and company is very specific. At the same time we are looking for generalisation. Classic Enterprise Solutions reselling large IT providers business often tend to offer over-generalised “classic” solutions. In contrary  GA treats specifics as “golden nuggets”, which make up wealth of a solution. The depth level of details, determining, recording and understanding specifics constitutes the quality of solution.

3. Review of existing architecture

At this step we do analysis of existing source code, the partitioning schemes, assess teams involved in the development and deployment processes - developers, architects, testers, BAs, prod support and last but not least (although often missed) - the management.

It includes discussions of overview, structure of the application, relationships of the packages, possible impacts this structure has on maintainability, performance and deployment; roles, responsibilities and relationships, runtime properties, performance review. Here we might discover issues of performance, reliability, deployment and partitioning. A written report of an analysis and a set of recommendations is created. Later it will be reviewed and altered many times.

4. Cross team collaboration

Team collaboration is often ia an existing problem and a focus for a solution. Taking a close look at it gives clues and saves lots of energy. See team dynamics section for details.

5. Low-cost unconventional approach

 

  1. Use Open Source can be “foot in a door” as a new concept acceptance exercise. Then the next step might be moving to a commercial enterprise version once the concept got  accepted. A new concept acception is much lengthier and complex process than moving to another product within same concept. For example BI Reporting concept acceptance is much more important step than later move from Actuate to Cognos.

  2. Often architects can find old homemade solutions, which do not fit current stack of technologies and thus stagnate and sometimes paralyze further development: old non standard authentication solutions, low level coding like some drivers, specific data storage solutions. Challenge teams to migrate to well known standard approach whenever it is possible, do not leave “under the table” such issues. Take in consideration a possibility of integrational work to do. Try Open Source as a “foot in a door” (see above)

  3. It may sound funny in this context but most cases of scalability, maintainability, reliability, availability, extensibility, performance, manageability and security often solved by moving to a J2EE cluster (do not forget DB clustering too). You would be surprised how many real cases just do not comprehend the value of such solutions even having in place some setup, licenses and skills. For such cases advocating J2EE best practices may do the job instead of bending backwards to find a suitable set of solutions. It might require development team dynamics focus.

  4. Favour quick prototypes mockups to demonstrate a solution. Challenge involved team members for quick demos. Talk in terms of days, not a long “serious” projects.

  5. Challenge existing processes if you see them wrong. If you recognised production deployment as wrong, tedious, lack of discipline creates havoc - raise the issue, develop, document and propose a new process instead of bending yourself backwards helping bad processes stay alive.

6. “Guerrilla warfare”

“Guerrilla warfare” here is a name for a situation and a number of techniques used to overcome usual resistance to change, attachment to old technologies, code, negative team dynamics in order to implement a solution. GA doesn’t hide such a reality but rather brings it to awareness, focuses on it in order to find best outcome consciously. See Team Dynamics section for more on this subject.

 

  1. Interview different teams including through company hierarchical levels, investigate the situation

  2. Try to positively challenge people from different teams to speak up, for new creative ideas, prototypes

  3. Give a new vision to management and teams. To give a vision you should have one and it has to be clear. If your vision is vague people will feel it and results will not be very satisfactory

  4. Mentor and advocate IT trends, which you like and strongly believe in, be truly passionate and sincere.

7. Team dynamics

Many issues and insights how to reach business goal can be found in team dynamics. In this context we are talking about team dynamics between groups and between people in a group. Almost same analysis, which relates to individuals, works well in dynamics between groups.

 

  1. Look for broken or lack of interactions between groups. It might be peer groups of developers not hearing each other or development-BA groups etc. Sometimes some of worst written code fragments and designs reflect hardest groups communications issues.

    1. Potential solution: organise natural flow of communication through pair work, ongoing team meetings between groups. Look at fixing communication as a solution for reaching business goal.

    2. Note: The latter might become a new source of problems: ongoing meetings preferably to organise between members (from different groups) who really need the communication to happen following their primary task, instead of creating boring lengthen meetings just for the sake of showing participation.

  2. Unequal participation can be due to cultural background, one of group is dominant, situational (eg. subdued for some historical reason).

    1. Once detected, bring it to awareness, management might might take a lead to fix the issue

    2. Note: Sometimes the issue might be in management preferences

  3. IT Developer’s decision often is based on their personal technology attachment. Often it suppresses others’ creativity and their own thoughts flow, making it impossible start using their imagination for other solutions and ideas for years. Sometimes it stops only when a key issue person leaves the company and then you can hear how others “open their mouse” telling how the creativity of the whole team was eliminated. And for some reason no one before could challenge it.

    1. Potential solution: independent from teams role like IT Architect advises for a direction and does overall analysis

    2. Note: IT Architect should stay conscious and be aware of a potential of getting involved into psychological games of  technology attachment and love/hate of existing technology choices.

  4. Lack of focus of the whole team. Keeping such team focused takes constant effort. Sometimes there is no right leader to keep team focused on task by assigning roles and enforcing accountability.

    1. Solution: give a vision of common goal, create a concrete agenda and distribute it prior to meetings. It gets people on the same page and will encourage them to prepare based on the topics under discussion.

    2. Potential issues: it might drain too much energy if the team becomes dependent on you. You want to teach “how to do it” rather than take a leadership role in this context. You are still IT Architect, do not take roles of others.

Team Dynamic corrections

Team dynamics corrections is a part of an ultimate business goal, has to be clearly documented, brought to awareness. It will be analysed later and tailored for a better fit to conform new requirements and findings on many occasions.

8. Business strategy

Here we look at business strategy in relation to a department (not always for the whole enterprise), which we are doing architecture for. It is an overall direction to the department/enterprise, and often requires clear boundaries to be defined first.

 

  1. Business strategy needs to start with stakeholders expectations and include all stakeholders. Note: reaching all stakeholders  might be a challenge

  2. To set managerial expectations in order to define decisions and actions for a long term performance. It involves formulating strategies to align the organisation to achieve defined goals. An identification and clarification of the purpose of the organisation/department and its plans are very important.

  3. It is very important to find, define, redefine and understand core competencies, which company does better than the competition, encourage and preserve a core ideology that fosters the company, core set of values to be able to maintain.

  4. I haven’t found one-fits-all method: a number of differing variables must be taken into account every time, and it is highly subjective and contextual process. Nevertheless Business Strategy step has to be done prior to the IT Architecture step and cannot be skipped. It is an embedded part of GA.

  5. Example: reporting application coding found to be NOT a part of core competencies and core business, as a consequence a decision to outsource the solution has been taken.

 

Add comment


Security code
Refresh



Powered by Investor Services. Valid XHTML and CSS.