It could be that my brain just thinks this way, but I’m baffled that people don’t intuitively create information architecture. For me this takes many forms like mind maps, application architectures, swim lanes, flow charts, whiteboard drawings, paper sketches, among other things. What could be more basic then drawing a bunch of boxes, connecting the lines, dot in the servers, show the user flow, and end up with a diagram for what you need to build. Or showing the step-by-step of a process and connecting the relationships between these steps.
For applications I create detailed architecture drawings that document the connections and information flow, but even if you are diagramming the relationships between non-technical parts of your business you are creating information architecture. The act of drawing this forces you to think hard about how your business, application, process, or whatever works. The resulting document becomes a valuable tool to communicate this thinking to others within your organization – technical or not.
For example, I recently did an assessment of a development effort that had lots of moving parts. But to document in a spreadsheet or deck that there was a lot of variability didn’t do it justice. It was hard to visualize. So I created a flow chart of the process, connecting applications to products, to development teams, to hosting environments, to downstream processes, to revenue, etc., etc… This gave a visual high-level view of all the parts, and graphically defined the variability in the system in a way that a PowerPoint bullet list couldn’t do. And as a result, discussion and decisions begin from a whole new level.
Base Assumption 1: Mind the Power Center
I’m a fan of iterative development. There are schools of thought that say “all you need are user stories”, or in extreme programming a desire to have as little documentation as possible and ideally none. But think about what this does. If your engineers are not collecting requirements from the business, then they have the control, and your power center is off balance. And to be fair, this is an overreaction from business who stifled development with the bureaucracy of over documenting and over analyzing.
Base Assumption 2: The Need for Product Management
This is why I believe Product Management needs to reside as its own department, in-between the others. It needs to have the discomfort of accountability to all departments, combined with the authority to enforce a disciplined documentation process. It needs the strategic capacity to identify ways of achieving the organizational goals with an insight for designing appropriate tactical solutions.
Base Assumption 3: Information Architecture is a Required Competency
A big part of effective Product Management is information architecture. Even if you are in a non-technical industry, diagramming process flows is an example of how IA can be an invaluable tool. I’m not saying you don’t need the PowerPoint decks, CBAs, business cases, and all the other tools. BUT information architecture seems to be left out, or mitigated to something done by technologists or ‘technical product managers.’ If you are not developing this skill within your product management team, you are missing a huge opportunity.
Assuming you buy into the resulting value of information architecture, here are areas where I think people miss:
Discipline 1: Make the Time
In my estimation people are in a rush to deliver something, anything. Make the time to do it right. Delivering something mediocre is just that. Every hour you invest creating good information architecture saves you days of time fixing what you built wrong.
Discipline 2: Quality
Make it kick butt. When I work on an application I want to dominate the world. I want it to be so great that the competition will just give up from witness to its fantastic awesomeness. But you don’t get this without doing a quality job, with quality discovery, and quality information architecture.
Discipline 3: Understanding
You don’t build a rocket without a rocket scientist, and you don’t build whatever you’re going to build without subject matter experts (SMEs). I don’t care how much you know about application development, YOU WILL FAIL if your process doesn’t incorporate the non-technical experts, the business savvy leaders, and the everyone else your business depends on. THEY know the day to day, not you. So take the time to sit down and understand what they do. Along the way, develop the working relationships you will undoubtedly need as new questions come up. And of course, put all you learn into your information architecture.
Discipline 4: Patience
Go through as many revs of your document as it takes. I’m losing my hair and there is a reason why – I won’t give up until it is right. Every turn of your diagram is one less time you have to correct your code. I guarantee this is a cheaper way to discover your mistakes, so do the work.
Discipline 5: Replicate Yourself
It is impossible for you to see everything across your project. And depending on the size of your project, you may need ‘specialists’ who focus on pieces and parts as you look to the whole. But either way, get others involved, and have co-ownership of the information architecture. Regardless of who is drawing the IA, make sure you both talk through the details before you build anything.
Discipline 6: Review, Review, Review
Once you have your document, go back to the SMEs and ensure that it makes sense to them. This will likely require some revisions, but that is a good thing – see Discipline 4.
Discipline 7: Focus on Core Objectives
You have to have a clear definition of your organization’s objectives, how your project supports that, and be disciplined enough to keep the focus. If you don’t have this, none of the rest matters.
Discipline 8: The Big One – Eliminate Yourself
Assume you will be fired tomorrow, so today is your last day of work. But, sort of like saying goodbye to a friend, you want to give it the best journey possible. Similarly, work your butt off today, and give your project what it needs to succeed. Document what you know, make sure others do, so if you get sucked into a black hole the project has what it needs to move forward on a swift successful trajectory. And how do you do this? By creating phenomenal information architecture!
I look at productivity and reward programs with a cynical eye. This isn't to say that reward isn't important, it is just the way it's done. For example, a paper "you did great" award that someone is going to tack to their cube is demeaning, especially when executives are rewarded in far more grandiose ways. Creating a truly inspired team requires a leader to turn this on it's head.
Rather than "Leadership" I like to think of "Servantship". I suppose this is essentially servant leadership, but I fear that concept has been mentally packaged up and hung on a mental hook in the back storage room of many leader's mind.
When leading teams I view my role as having two unequal parts.
Team Leadership
The first, but smaller part is to:
- collect information from the team
- direct discussion about the important topics
- pull the right decisions out of the team
- make sure the direction that gets set is informed by the team and in alignment with the business
Leading with the team, rather than TO the team, is so much more effective, hands down, period. The reality is that when your team is aligned to the goals of the organization (OG), and the project execution (PE) is designed to directly impact these goals (PG), by association the goals of the project directly support those of the organization (PE + PG → OG).
Of course, making this successful assumes you get great people on your team. I think that hiring strategy is something that you are continuously learning how to do well. Jason Fried, CEO of 37 Signals has some good ideas about writing a job description that have worked out well for colleagues of mine, and is something I'll be testing out.
Support Support Support!
By FAR, this is so much more important than leading. Sort of like location in real estate, amazing leadership is all about supporting the team. Disagree? Then you probably aren't someone I want to work for, and my guess is that your team isn't happy about it either.
What keeps me up at night is when there is something I can do to keep my team moving. I'll work to the early hours of the morning or over the weekends if it means that I can keep my team moving.
One of my first bosses had this quality. I was in college working for a remodel construction company. We were contracted to rebuild a parapet wall along the top of a mall that had been damaged in an earthquake. It was over 120 degrees on that roof, and our crew was working with another sub-contracted team. While the other team's leader sat down in the cool air conditioning, our boss cam up with cold drinks then helped us move and place 3/4" plywood sheets. He was a great leader, and this wasn't abnormal for him. But the stark contrast between his behavior and the leader of the other team really stood out.
I think about that often. It's one of my favorite business memories. And as I lead teams I think about what I can do for the team. It might not be cold drinks and moving plywood, but as a metaphor, in whatever I do I'd like my team to feel that I am a part of the team and there to do whatever it takes to support them.
The Downhill Roll
Working in start-up companies has given me a short cycle time with employment, and the opportunity to work for a wide range of leaders. The other thing it's given me is visibility to the top. Even where I've had a boss between the CEO and myself, it is easy to see that the company culture is set by the CEO. Even a great boss can not completely shield a team from a toxic environment (although to the extent possible I think this is part of the 'support' role).
In "Good to Great" Jim Collins does a great job of delineating the difference between Level 4 and Level 5 leaders. Of course nobody is an exact match for one or the other, but as I think back, the better leaders tended to be more like the Level 5, and vice versa. I recommend picking up the book if you haven't read it - or my preference, the audio book and listen while you drive & fly.
>>
Level One: A capable individual who makes productive contributions through talent, knowledge, skills and good work habits.
Level Two: Also a team member, he contributes his individual capabilities to the achievement of the group objectives and works effectively with others in group settings.
Level Three: A competent manager. He knows how to organize people and resources towards the effective and efficient pursuit of predetermined objectives.
Level Four: Goes one step further and becomes an effective leader, he catalyses commitment to and a vigorous pursuit of a clear and compelling vision, stimulating higher performance standards.
Level Five: The person who knows how to build enduring greatness through paradoxical blend of personal humility and professional will.
<<
Rolling the Right Stuff Downhill
I had a leader tell me once that he was impressed with my passion, and told me to never lose it. When I'm doing what I do best, getting paid fairly, and aligned to the goals of the organization, having passion for what I do isn't a problem.
But it begins with leadership. If what I'm working on isn't making an impact to the organizational goals, and helping build a great company, there is nothing to be passionate about. The role of leadership is to create a culture with the right people, doing the right stuff, aligned to the right direction.
This brings me back to hiring, support, and Moneyball.
1. Hire people with potential. People who are hungry, anxious to do great work. People who, when you interview them can't stop talking about how they love to do whatever it is that you are looking for - even to the extent that what they do is their hobby that they get paid for. Go rent the movie Moneyball.
2. Align your project to the goals of the organization (this makes the work meaningful).
3. Get your team involved in planning & decisions. With them engaged in the process, the group inherits a strong sense of ownership, and will be extremely driven to deliver.
4. Give credit where credit is due - which is always the team. I like to participate in the great work, but I'm acutely aware that without the great people on the team, the results wouldn't be what they are.
5. Support the team however you can. If there is a problem, fix it.
6. You are accountable. If there is a failure, you probably didn't align the team with the right goals, so it is yours to take.
Want to eliminate passion in your workforce? Detach them from the organizational goals, limit their visibility, and implement a bunch of silly rewards programs.
Want a highly productive team? Roll the right stuff downhill. Besides, inspiration rolls easier and faster than commiseration and complacency. Not to mention that it is more fun and delivers better results. Which makes me wonder why there are so many lackluster leaders - I just don't get it.
I'm sure you've put together a few Power Point decks and modeled data in Excel. Both are great tools. But are you taking advantage of information architecture (IA) to make strategic decisions?
When using IA for strategic purposes it may end of looking more like a mind map. Although mind maps tend to stem from a common "seed" idea and branch out. I'm a fan of making lists of related things, and using connecting lines to demonstrate cross dependency. The more related lists you get, the more inter-related cross dependencies and touch points.
One thing that will become apparent very quickly is if you have a high degree of variability in your diagram, characterized by multiple intertwined many-to-many relationships. Note that many-to-many relationships aren't bad per se. If you have a clearly defined process that minimizes the impact of these relationships it may demonstrate the mature capability of your system. On the other hand, when variability and cross dependency are the rule, what you are seeing is an undisciplined approach that introduces significant risk into your business.
But here in lies the value proposition of strategic IA, especially considering that many people are visual learners, but can't visualize from a bullet list on a Power Point or connect the dots between numbers on a spreadsheet and the underlying processes that create that number.
The trick is finding people who can create the IA documentation. It takes more than just knowing how to draw this type of documentation. You need to have an understanding of business, operations, clients, technology, or whatever the relevant pieces are that drive your business >> or more to the point >> someone who is capable of learning these pieces, and represent that as they draft the IA.
See my post "Legacy to SaaS Transition? Mind the Gap!" and my thoughts on the role of product management. I believe that this type of IA documentation will naturally result from the discovery process. And in my opinion this type of documentation is an essential part of Product Management, because it enables better strategic design within the organization by maximizing the discovery time invested with a comprehensive output that is visual and easy to quickly understand. I'm tempted to post examples of the strategic IA work I've done, but as you can imagine all of my work contains confidential intellectual property.
Finally, for this to be effective senior leadership needs to embrace this as a learning mechanism. It isn't that Power Point decks and Excel models and CBAs aren't just as relevant. But the IA diagrams create the context for all of this to come together. Without being able to "see" what you are currently doing, and "see" what the impact of the proposal will be, conceptualizing the reduction of risk, or the expansion of capability, or the impact to clients and operations, etc., is difficult. At the very least it can give some perspective about why a significant investment is worth it, or why a problem is worth fixing, and so on.
With Software as a Service (SaaS) coming to maturity in the last several years, and the market valuation of companies embracing SaaS/Cloud/Web technologies, there is an exodus in all sorts of industries with businesses migrating from legacy infrastructure. And for good reason, SaaS offers all sorts of benefits.
But I've noticed a gap that if left unchecked can become a significant area of risk.
Empirical Understanding
On one hand you have people with empirical understanding. These people know what the business does in a hands on way - empirically. They know the process step-by-step, into the details, and "WHY" the business does "WHAT."
Pain:
- Slow and lacks automation
- Runs on old technology or hand done / paper processes
- Uses a "throw people at it" approach
- High cost
- An empirically based understanding
- A depth of understanding into the details
- The foundation that allows the business to get the service "right"
- Products, services, and support that are based on this knowledge
Technical Capability
On the other hand, businesses either develop in-house talent or retain outsource vendors who have strong technical capability. These teams build better ways to do what the business does, replacing slow or manual processes with automation, and extending areas of control to clients.
Pain:
- Requires significant upfront investment
- Requires time to build
- Requires the right people to develop
- Requires the business embrace a new way of doing business
Benefits:
- Current technology with lower cost of ownership
- Transitions human cost to clients
- Gives clients the control they want
- Can create a cross business platform
Risk In The Middle
The gap between these groups is almost a "generational" gap, where the empirical "legacy" generation is eventually eclipsed by the new technical "SaaS" generation. But so what? What is the big deal?
Think first about the complexity of your businesses. Your operations people fulfill your products or services, they don't build or understand technology.
Technology is capable of providing tools that solve complex problems. Technologists build tools, they don't fulfill your products or services.
If you do not form a plan to bridge these two groups, you will effectively build a "generation gap" into your business.
Solving this at first brush may seem easy, but consider the following:
Empirical Knowledge:
- Does your leadership have a deep empirical understanding of your products or services?
- Do you have mechanisms in place that help facilitate this understanding with leadership?
- Do you utilize these mechanisms to help communicate this understanding to your technologists?
- If the answer to any of these is "no", are you planning to implement learning mechanisms?
Technical Knowledge:
- Does your leadership have a deep understanding of how your technology is built?
- Do you have mechanisms in place that help facilitate this understanding with leadership?
- Do you utilize these mechanisms to help communicate this understanding to your operations people?
- If the answer to any of these is "no", are you planning to implement learning mechanisms?
The Role of Product Management
Senior leadership is always incredibly busy. So the first thing I would say is that if your business is considering or beginning a migration from a legacy platform to SaaS, an investment of time from leadership is critical. That said, the goal should be to maximize the time spent by leadership. But the same is true of your operations and technology development groups.
Product management should take a leadership role in facilitating the information share and learning. Moreover, the design of this approach should work for leadership, ops, and development.
This isn't to say that product management should become a training team. You may also need create such a team, but product management should be blazing the trail.
Why product management? If you are going to evolve into a SaaS based company, you need to evolve your product management competency to support this. You will need product managers who come from both sides. Technical PMs need to take the time to thoroughly understand the business, and business PMs the technology. How else can you possibly manage SaaS based products?
What you end up with is a small group that sees both sides of the fence. This should be reflected in the product requirement documents, application architectures, functional specifications, executive summaries, business cases, and the myriad of documents that come out of product management.
From there I'm a big fan of web-based video. This may be where you incorporate a training team who can take direction from product management on the "who & what" to film. Video is a great format, is inexpensive, and becomes a powerful tool. You can easily do interviews, screen capture, and film the white boarding of concepts, to name a few things. It is a "do it once, reuse it many times across multiple locations" format. And when you shoot internal-only video, production value takes a back seat to the value of training, and the speed of the impact. Moreover, it is a SaaS based tool, and if you are transitioning to a SaaS platform it is a great way to embrace the concept to build internal competency about the concepts.
Take Away
Obviously there are a lot of ways to skin the cat. But if you are transitioning your business to SaaS, don't just hope that somehow your business will learn the new technology, or that the respective groups will educate each other. To be successful you MUST design a disciplined plan that:
- has product management blaze the trail
- uses tools and/or groups that can educate
- creates content that trains SaaS to operations, and in-house competency to development
- and both sides to leadership
Now Zoom Out
Reconsider that many businesses in many industries are going through a similar migration. And the marketplace is demanding the same Web/Cloud/App based user experience with their business applications that they have with their personal applications. And if it hasn't happened yet, it is likely that your competitors will soon be considering SaaS/Cloud/Web/Apps to support their clients.
Now consider your approach to a SaaS migration. Businesses who win don't just do whatever it is, they do it better. So don't just rush at SaaS. Slow down, migrate better, set the stage for better ongoing execution, and win.
When I was a kid I needed to learn how to swim. But I wanted nothing to do with swim lessons. They finally duped me into being the "teacher's helper". And soon enough, I learned how to swim.
I've always been slightly embarrassed about this swim lesson story. But lately I've been thinking a lot about project execution and alignment to the corporate strategy. It occurred to me that throughout my life there have been many times similar to the swim lesson event, although not always as contrived. Nonetheless, for me to participate at all I needed to be tightly integrated into the leadership of whatever it was.
This isn't to say that I have to be the one in control - just involved. In fact, I've noticed that for me to get really excited about a project, I need to have a team of great people around me. I know that I don't know everything. And I might be a good point for some projects, and not for others - but I'm happy either way as long as my contributions are focused on the success of the overall project.
In large organizations it is easy for all of the strategy to be trapped at the top of a vertical org chart. And you could argue that because of their background, experience, education, and so on, their purpose is to be the strategic component of an organization. You could also argue that because of their level of responsibility, they are too busy to spend much time down in the trenches.
I believe there are ways to overcome these things. In fact, Jim Collins in his research for "Good to Great" found that the majority of GTG companies had CEOs that came from within the company, and the comparison companies far more often had CEOs that came in from the outside. The immediate correlation is that if you have swept the shop floor, driven the fork lift, done the grunt work, and worked your way up, THEN you understand how the business works. You have a deep understanding that someone coming in from the outside can't have.
At least, they can't have it without going through a discovery process. Having worked in many different companies, industries, and departments; and having developed applications that have modules serving many departmental workflows simultaneously; I've learned the skill of learning how things work through a discovery process.
The first thing you need to do is make time. The second thing you need to do is take notes, make lists, draw flow charts, and whatever it takes to capture and document the way things work. And finally, you need to amalgamate all of this into a cohesive document as if you are going to present it - even if it is just for yourself.
This effort gives you deep understanding. It gives you working relationships. It identifies opportunities for improvement, competitive advantages, and connects the dots. Without all of this it is difficult, if not impossible to have a clear understanding of the right strategic direction. But this effort can result in a perspective similar to that of a leader that spent years rising up within the organization.
Now consider the working relationships piece of that. When you've spent time with the people doing the work, they get to know you, are able to contribute to your approach, and feel like they are involved in the process.
In a large organization this almost becomes more important. Cultivating this understanding throughout your leadership is critical. And more than just reaching down within their own departments, it is essential to do cross-departmental discovery. Follow the process from beginning to end, point of sale to fulfillment, infrastructure development to client support.
The depth and breath of your leadership's understanding, the better your ability to make good strategic decisions will be. AND the organization will benefit from the foundation of the working relationships. Leaders will understand who does what, and the people on the teams will be more aligned to the strategic direction.
Conversely, when strategy is all at the top gaining alignment down the ranks is difficult if not impossible. If leadership doesn't understand the organization, people don't know how to align. If people don't have rapport with the leaders, they aren't motivated to align.
Finally, if people are motivated to align to your strategy, they will be more productive. On one hand, you eliminate most of the "out of alignment" work that would have been done with "in alignment" work. You also boost the overall enthusiasm the workforce has for achieving the goals of the strategic direction. When people are focused on the right things, and passionate about doing these things, it becomes a great recipe for productivity.
Obviously there are many other components to creating a high performing organization. But if you don't take the time to get the deep understanding and build rapport then you won't foster alignment or motivation, and subsequently high productivity.
I'm not a gambler, but I like to play in Vegas. I don't play because I'm looking to hit it big and retire to a life of comfortable irrelevance. For me, the allure is an empirical touch point for luck, combined with the short cycle time, and tangible feelings of winning or losing. Next time you are in Vegas, you have to play - even if it is just a little.
>> I put $20.00 into a penny slot, 1 cent per line, 9 lines, 9 cents per bet
I think most people think about luck as something good or bad that pops up out of the blue. You do nothing and there it is.
I'm going through "Great by Choice" (Jim Collins & Morten T. Hansen - go buy it) for the first time, and there is this great concept, paraphrasing roughly "It isn't whether you will have luck or not, but what you do with the luck you get."
At one point, I was put in charge of a small project. It was a proof of concept at a particular level. But there was opportunity to be had.
>> The penny machine stats hitting, I double the bets, 2 cents per line, 9 lines, 18 cents per bet
Over the course of the next year I worked hard. The project grew. I had a phenomenal team of people working with me. We were getting recognition for our work, and it felt great.
>> The machine is ticking along, I'm up, and go to 5 cents per line, 9 lines, 45 cents per bet
Then, as I was preparing to launch into an new wave of development that will expand the application into a fully fledged platform, the business shuffles the projects and sends the development work to another part of the company.
>> The machine loses steam and I'm down, way down.
But there is a silver lining here. I was smart about the way that I developed the code, and how I had built my team. I was lined up to reuse that code for other purposes and had a smart team with solid working relationships that were locked and loaded.
>> The machine is up and down, but the bottom isn't falling out
As I headed into the next project the stage was set for a quick ramp-up and an accelerated deliverable schedule.
>> The machine was climbing again
Even in cases where the worst happens and it all falls away, you have to always be thinking about how what you are doing now prepares you for the best AND worst case scenarios. This is your job as a leader, so when it all hits the fan if you don't have a plan B the finger of responsibility only points at you!
>> I'm part of a players club, and earn points for all the money I "invest" into the machine.
I've lost my job more times because the company I worked for went out of business - but that is the high risk nature of the start up world. But things happen in large companies as well, because you are battling other strong wills, leaders who are overwhelmed and under informed, and have to work with people who don't always have the background they need to make the best decisions. It's life.
>> When the machine is out, at least I've earned some points that will help me get good offers on discount hotel rooms for my next stay. See, it REALLY is "investing" after all!
Several times I've worked on projects where aging mainframes or early web architecture is either causing maintenance pain, or forcing a rebuild all together.
In the case of main frame systems it doesn't just look bad, you see hardware that reminds you of the "fax machine beat down" scene from the movie Office Space. And until developing with multiple application layers reached maturity, many apps were build with the business logic in the HTML files making updates difficult and timely.
Given these technical limitations, business leaders have had to deal with high costs, long time lines, and nominal value returns. And just because a better methods exists, it doesn't mean that all development is equal or good. So it is understandable that business leaders are wary of new development projects, since they may be high cost and result in the same frustrating situation.
To make matters worse, most business leaders don't have a technical background, and have to rely on the consultation of tech leaders who themselves are not always up-to-date on the latest technology trends. Not that I'm an expert per se, but I do surround myself with people who are - and based on successful experiences in application deployments I've developed an approach SaaS platform design.
This shouldn't be a unique approach, as it is built on best practices. But because of that, I feel like it should be a well tested solution infused with standards that transcend my (or anyone's) individual experience. So I'll call it "my approach" since I'm presenting it here, and because I've personally implemented it with development teams.
My approach to platform design allows your data to be maintained, independent of technology. It allows your applications to be developed and maintained without the limitations of the hardware or UI. It allows your UI to be flexible, and adapt to design trends, new device environments, and better client side technologies. And finally, it makes your hardware cost an ongoing maintenance cost, with the benefit of the best hardware available, and the avoidance of high cost total system replacements.
Learning from the past, the things that have since been fixed are hardware and the user interface (UI). So the question is, how do you break this limitation as you design forward?
The key is to modularize your application. At a high level your application development looks something like this:
A) Client Interface
B) Business Logic
C) Data
D) Hardware
Within each layer there are modular components.
In the Client Interface for example, you'll have CSS, JavaScript, other include files, and so on. And these may be further broken down by application area, component, or conditional need. The obvious advantage here is that you can make updates to one location and have it populate throughout - a one to many time saving solution. Another advantage is that you can create programatic conditionals that affect display, such as co-branded or white label skins.
When you work with highly scalable providers like RackSpace, who have almost magical ability to spin up / down environments you are experiencing hardware flexibility. This ability stems from technologies like RAID servers (redundant array of independent disks). I've been lucky enough to be in hosting facilities and witness RAID servers be pulled from the back of a live site, a replacement inserted, and the replication process begin.
In between these two layers you have your business logic and data.
Most of your development effort should be focused on the development and maintenance of your business logic. And over time, the accumulating client data creates value. But by removing dependency on the UI at the top and the hardware at the foundation, these layers can "float" between, or allow updates to these to upgrade with the progression of hardware and UI development trends.
Adding better security and load balancing to this scenario is now possible, and gives you an architecture that looks something this:
-Firewall [[security layer 1]]
- Load Balancing
A) Client Interface >> design trends >>
- Web Services
- Firewall [[security layer 2]]
B) Business Logic ((development & maintenance))
- Web Services
- Firewall [[security layer 3]]
C) Data <
D) Hardware >> hardware improvements >>
This increase in security is critical, especially for any application that maintains / touches the personal or financial data of its clients.
The load balancing enables application scaling, but it can also allow for transitioning to a disaster recovery environment if necessary.
With these things in place, the technology developed is not only easier and more cost effective to maintain, but has a much longer shelf life. Making the decision to transition to such a platform may be difficult, but from a cost/benefit perspective, the long term benefits should outweigh the up front hurdles and deliver a break even in a reasonable time horizon - even with conservative projections. There are several ways this is realized.
1. Lower technology maintenance costs:
By eliminating the struggle to maintain a rigidly entwined application, UI, and hardware, your technology costs should be reduced or redirected to things that provide higher ROI.
2. Current/better hardware:
By keeping your hardware current it's a given that you make regular updates to the appliances, meaning regular investment. But you avoid the pain of maintaining old hardware, and you distribute the update cost over time rather than getting hit with a huge balloon cost when you are forced to get current.
3. Better technology development costs:
You can focus almost all of your engineering effort directly into the logic of your applications. This should give you better applications over time (assuming you are disciplined in your development and maintenance approach) which translates to better ROI.
4. Increased retention & growth:
Because your applications will be better, they should provide better service to your clients. Of course this assumes you are disciplined in your client engagement approach. But if you do this well, you will increase client retention and growth.
5. Easy, cost effective scaling:
With a larger client base you will need to scale your environment. But because you have removed your hardware dependency, you can scale your physical environments to meet demand, paid for out of revenue. And if your business is seasonal you can scale up/down as needed to manage costs (this assumes you are leasing overflow environments).
6. Momentum:
With all of these things working together, you will develop momentum. Upgrading servers - no big deal, just replicate and go. Upgrading the UI - no big deal, just design and deploy. Adding new features - easy.
7. Competitive advantage:
We are at an inflection point. The dot-com bubble innovated a new way of doing business. The last 10 years adoption of web technology has been adopted and proven in large industry segments. However, the early adopter behavior of this technology, especially by non-web businesses, has not been designed to "move with the development of technology". Therefore, if you update to a flexible format, you can be more nimble than your competition, and your platform becomes a catalyst for great marketplace performance.
