Enterprise Architecture: From Incite comes Insight...

A lot of our problems with documentation come from the significance we invest in it. Culturally speaking, we tend to believe what is written down somehow must have more truth than something learned through other means...



Last year I asked the question: Is it possible to create too much documentation? Now I am asking whether one should even bother reading existing documentation.

Is it wise for an otherwise logical group of IT professionals to believe in something that they know is almost never true? What if we simply started with a simple guide as to what documentation is used for and more importantly what doesn't have fiscal return in documenting (If you have documentation in a contract, you are already a loser).

• All documentation is to be distrusted as out of data and subjectively biased


• Always favor a conversation over reading documentation...Its out of date, subjective and conversations may uncover insights that documentation would have missed


• If you don't know who to talk to, look at the documentation to see who writes the most notes about the bit of the application you're interested in


• Use a slick editor and hide all the code. Simply read the comments left by previous developers. If you are wondering why some function doesn't work and you run across the infamous TODO comment then things become clearer

Have you heard of McGovern's law of documentation which states: The likelihood of keeping all or part of a software artifact consistent with any corresponding text that describes it, is inversely proportional to the square of the cognitive distance between them. For those who like things more simple, this translates into out of sight, out of mind....

Throughout my career, like anyone else I have had both good and bad bosses. Today, I will share a few characteristics of the good ones...



Sometimes, a boss suffers from power poisoning. They become selfish and oblivious to those around them. They have the ability to insulate and protect those below them, but otherwise choose not to. The best of bosses serve as a metaphorical condom and is savage in protecting their people especially in situations where perception management has gone awry.

Enterprise architecture when practiced correctly does require not only the positive aspects of championing ideas that lead to sustained competitive advantage but also attempting to destroy ideas that can lead an organization in the wrong direction. When an enterprise architect strives to be a steward of the enterprise, others may frequently take his/her actions as personal attacks. Protection of people at this stage is vital not just for the individual but the overall success of the organization.



At the time you make a decision, no one knows whether it is right or wrong. But research shows that if you, as the authority figure, act confident about implementing the decision, it increases the odds of success. If you lack confidence, people will be less committed to your decision. They have less faith in you as a leader.

A leader will champion your ideas and help amplify them in order to increase the potential for success. Those who are simply managers, may see this as an opportunity to be an emotional vampire.



Have you ever ran across employees who love being martyrs for their abusive bosses. People who, if they didn't have their boss to complain about, wouldn't know what to do with themselves. But in the end, even people who are masochists are going to suffer all kinds of physical and emotional health issues if they stay in a toxic environment.

The best of leaders are thoughtful not just about delivery of work products, but the physical and emotional health of their employees. Many haven't thought about this as just a casual observation, but as a deliberate action to improve. Some have encouraged employees to get out of the office and to do meetings outside when the weather is nice while others encourage employees to take walks while meeting with others.

There are probably other characteristics I am not thinking off, but these are at the top of my mind right now...

The biggest difference between a great organization and a mediocre one is the fact that leadership recognizes the emotional vampires amongst its ranks and slays them...



Emotional vampires come in various shapes and sizes. Despite the several sub-types, one factor that they all have in common is that you feel emotionally drained after spending time with them. Besides feeling drained, they often take up your time and in some cases money as well. Emotional vampires tend to run in families. If you encounter one, you will want to avoid it and their family members as well.

There are people in this world who do everything in their power to boost your spirits and fill your heart with hope and joy, but then there are also people who will do everything in their power to bring you down and drain you of all your hope and joy, and those are the ones who can be considered 'emotional vampires.'

It is not unusual for emotional vampires to be in crisis and have ways of ‘hooking’ you into their crisis. Once hooked a kind of bonding takes place. Since you went through a crisis with them, they expect you to stay with them. Other vampires use coercive tactics to get you to agree with them, even in situations where you know better.

Vampires aren't concerned with your overall well-being and will be the first to cause you to lose work/life balance, often employing tactics that make otherwise simple tasks harder than they should be. Sometimes, vampires hide behind more altruistic sentiments by championing goals larger than themselves but otherwise are solely focused on their internal demons.

Inversion of control is also used by many vampires. Imagine a scenario where you are frequently given tasks that have been known to take say eighty hours yet the vampires place a demand to have them done in forty. One could chalk this up to a form of blissful ignorance but vampires take it much farther.

In today's workplace, whether you work for the largest of employers or the smallest, the increasing importance of getting culture right trumps the best of methodologies. The number one and two companies in industry vertical also tend to excel at having the best cultures while the bottom companies the inverse is true.

While financial metrics tend to be the yardstick, they mirror the culture of an organization. Too many executives are focused on the finances and not enough on the culture. If employees feel drained, then how can productivity and innovation occur? Can we all acknowledge that quality of delivery is increased when morale is rising and that we all feel positive about ourselves and those who surround us?

I remember a conversation with Calvin Hudson, who was EVP of Claims at The Hartford. He talked about how he had to slay a vampire within his organization that was draining the souls of employees in his organization. As a leader, he was fiscally responsible but also kept an eye on how he wanted his organization to feel. He frequently met with employees of all levels and worked constantly to slay vampires.

If your organization isn't hitting its numbers, employees are starting to leave now that the job market is making a turn or otherwise IT delivery continuously lags, then I suspect your leadership hasn't spent sufficient time figuring out who are the vampires in the organization and slaying them...

A real deadline is one that really matters from a business perspective whereas an artificial deadline was chosen for arbitrary reasons. While some deadlines should be ignored or at least mitigated, the real ones should be respected. Sometimes, the difference between the two is not so obvious...



So that folks can get their heads around what a real deadline feels like, here are a few examples:

• The new toy, game or widget must be ready for Christmas sales


• The rocketship, space shuttle, etc must launch by this date, otherwise we will miss some opportune and relatively infrequent planetary alignment


• If the demo isn't available by Oracle OpenWorld, Gartner EA Conference or OWASP Summit, that would be bad

Unless you are from the school of thought that everything is important and that you should never say No regardless of how ridiculous the request, then I think I have made my point. For others who don't get it, I suspect they are in the minority where they are companionless and have no meaningful life outside of work to speak of.

Anyway, the artificial deadline has other behaviors attached to it. For example, you may find yourself having meetings that need meetings to plan them and then more meeting to spread their results. Projects are proposed, formal proposals are drafted, reviewed and redrafted, approved for submission, submitted, approved and then after all the beauracracy, the team is only left with a few days/weeks do to all the work before the "deadline".

Tasks then get assigned to anyone who is free (regardless of whether they are the right person) and overly quick turnaround times are requests. How did we get here? Because someone picked a date out of the air.

The next time you here a phrase that sounds like: The customer wants X by July 1st you need to figure out if this is a real or artificial deadline. If you can talk to the customer and get the deadline moved, then it is artificial. A situation such as "I promised the customer the product would be ready by July 1st, so they've scheduled a demo." is a way of converting an artificial deadline into a real deadline. Conversion of artificial deadlines into real deadlines is a mark of poor management...

The tactic of using artificial deadlines has been in existence since the birth of IT. Sadly, this practice is about as good as a one trick pony...



Part of the theory of using artificial deadlines is another fallacy in believing that people think faster under pressure. People can be more productive for a short term when under pressure because they:

• Focus attention on the important tasks


• ignore low-priority tasks

However, this is not sustainable because tight focus leads to burn out and when combined with ignoring low-urgency tasks (distinct from low-importance) such as refactoring code, cleaning the kitchen, etc) a lot of things just don't get done.

An important time-management and stress-management technique is to set priorities, and then address each task in a focused-but-unhurried manner. You can never do everything you want/should, so focus on the tasks that have the biggest payoff. Trying to "work harder" doesn't pay off.

The one important but often missed fact is that people do not think faster under pressure but they do think differently under pressure. They may be more focused, but they're not necessarily focusing on everything that needs to be done. Pressure places people in a specific mindset, and that can have massive repercussions. This is why stupid bugs can get introduced during peak development times, because folks are in that anxious, sharp-minded time when they're focusing on specific things, but not necessarily all the important things.

Did you know that the human body allocates resources away from the brain while under pressure? Both adrenaline and cortisol allocate more resources to muscles, and away from immune system, digestion and your brain. So under stress you're also more likely to become ill, or have digestion problems.

Adrenaline dumps resources into the bloodstream, shoves your heart and lungs into overdrive, overrides safeties on muscles, kills the safeties on the immune system, and on your brain too. Increased blood-pressure might have you "seeing red", overpower in your muscles might have you trembling and you may notice a distinct decrease in your ability to reason logically. Hopefully you won't need much adrenaline in your job.

Cortisol works by modifying your physiological pathways on the long term so that you will react more properly to physical problems in the future, including making adrenaline bursts more effective. Cortisol production goes up if you are experiencing psychological or physiological stress in your work.

Since IT is about developing high quality valuable working software and not the manufacturing of cortisol, what can we do to get focus on less stress as a way of creating more productivity?

Throughout my career, I have participated in a myriad of "proof of concepts" in a variety of technologies. The notion of a POC is an opportunity for a vendor to put their best foot forward and demonstrate their value proposition to the enterprise. With that being said, many vendors repeat the same mistakes...



I am going to outline five considerations for vendors who want to improve their game and point out several observations I have noticed over the last three proofs of concepts I have participated in.

Overly aggressive sales: Sales people tend to be aggressive by nature and highly competitive. Sometimes their behaviors get in the way of doing the right thing and can exhibit certain tendencies that can turn off a client. Sometimes a POC is a dynamic environment and changes due to a variety of reasons whether it is due to the infrastructure staff not getting an environment ready on time or simply a clerical error in describing the requirements. The key thing is that mistakes will happen and it is not in your best interest to always point out faults made by your clients even when you think they may provide an advantage to your competition. If you truly believe in your product and overall value proposition then being agreeable and working around any impediments that emerge will get you more cool points than pointing out every flaw in execution.

Bringing the Entourage: When an enterprise customer attends a demo, it may be the first time that they are meeting others within their own company and therefore are already burdened with learning a few new names. When a vendor brings an entourage, this only serves to challenge those who have difficulty in remembering names struggle even more than they should. More importantly, it sends a subconscious signal to the individual that may be interpreted as negative. After all, if a product demo requires ten people, then how many people are required in a production setting.

Scheduling: I did some analysis of vendors in my previous position who were selected to go forward with and noticed an interesting pattern. In life, you always remember your first experience and last. This doesn't just apply to things we won't talk about in polite company but to the selection of a vendor as well. Being in the middle causes you to be a blur. The first vendor has the advantage of establishing the tone and the opportunity to educate the customer on the problem domain while the last vendor gets to leverage the hard work of others and in their finale, finishes off with a resounding crescendo. Pay attention to when you are scheduled relative to your competition.

Following a script vs having a conversation: Imagine a scenario where you have lots of highly titled individuals in the room. You need to ask yourself whether they even have the time to sit through an arduous PowerPoint presentation or may need to depart for other pressing matters. It is almost guaranteed that even if they sit through a long scripted presentation, the simple fact that they are executives probably indicates their inability to hold a long attention span as to be successful in this role requires extreme content switching. Sometimes, it is a best practice to put down the PowerPoint and to simply have a conversation. Don't worry about whether the employees of the vendor can follow along, it is more important for the enterprise customer to get it.

Food: Ever heard of Maslow's hierarchy of needs? If you are going to schedule a meeting at 10am, you should consider bringing coffee. If you are going to schedule a meeting at 2pm, you can probably count on the fact that people are suffering from the afternoon lull and want to doze. A healthy dose of freshly baked sugar cookies will cause an insulin spike that will help people over the hump and won't cost you more than $20 in quantity.

Vocabulary: Vendors have become very good at adopting industry terminology for the concepts their solutions represent. The challenge is in when enterprise customers use the same terminology but otherwise have different meanings, sometimes this results in a miss. Some people are into relationships, others into the technology and so on. The one role that you need to figure out is the person that is leveraging their intuition to read the audience. Don't assume that agreement and head noodling is only limited to the Asian culture.

Trinkets: Many vendors have cut back on their marketing budgets and have eliminated the trinkets. While I respect financial discipline in doing this and wholly agree that this results in waste when done in a conference setting, I tend to think that there is still value in doing so when a person is in their home turf. When I am at a conference, I am now dealing with baggage fees and probably could benefit from not carrying additional stuff. However, if I am an employee of a large enterprise and you are doing a demo on my premises, it is very easy for me to carry back trinkets to place on my desk. Denying someone the opportunity to walk away with something that uniquely brands you is penny-wise and pound foolish...

Leadership is not about command and control nor in creating a perception where everyone is in agreement. Great leaders lead all people under their care, not just those who agree with them...



As much as some don’t want to hear this, there is an “I” in team because teams are comprised of individuals. If you crush the individual character and spirit of those who form your team, how can your team operate at its best? It cannot. The strongest teams don’t weed out or neutralize individual tendencies, they capitalize on them.

The goal of a leader is not to clone him/herself, but to harness individual strengths for the greater good of the team and for the overall benefit of the organization. This is best accomplished by leveraging individual talents not stifling them.

I would be less than candid if I didn’t admit that leading those inclined to follow is significantly less of a challenge than leading those who don’t want to be led. Anyone who has ever been in a leadership position has had to deal with the inevitable tough relationship that causes more than its fair share of brain damage.

At some point in time we’ve all been involved (directly or indirectly, willingly and unwillingly) in the corporate politics of turf-wars, empire building, perception management, silo-centric ignorance, title inflated ego and arrogance, and the list goes on… Regardless of the idiocy in play, it is a leader’s responsibility to effectively lead not only those that agree with their position, but they must also lead those that hold dissenting opinions.

There are always those who choose to oppose or undermine authority, but that in and of itself does not remove the obligation of a leader to fulfill his or her duty. While likability is a great asset to possess as a leader, it is not essential. It is however essential that you have the respect of those you lead. Respect is earned by honoring commitments and doing the right thing for your people regardless of punishment or reward.

It is through making good decisions that are wins for all parties along with placing the growth and well-being of your people as a top consideration and combined with honest communication that you earn respect and maintain rapport even with those who are not necessarily your greatest supporters. Here’s the thing – do this well enough and consistently enough, and you’ll find that most of those who once worked at cross-purposes to you, are now gladly working in concert with you...

Anne Thomas Manes of Gartner once declared that SOA is dead. Today, I am declaring that Data Warehousing is also dead or at least braindead...



The data warehouse is dead. Age-old methods of gathering and storing data into centralized warehouses, transforming it into information and generating reports, are inadequate and do not deliver either speed or intelligence to the enterprise.

The cost to create a single data warehouse in a Fortune 100 shop is estimated to be nearly $5 million, with additional yearly maintenance costs running around 20% of that figure. Add to that the complexity of report generation, married with the inability to easily connect disparate information sources, and you have an information technology phenomenon of unprecedented proportions that is not just costly but mostly irrelevant to the day-to-day needs of business managers.

It is important to acknowledge that there will be lots of people continuing to waste money keeping things on life support. Anyone care to guess how many mainframes IBM has sold to customers within the last five years that never had one in the past? Know of any software companies that started to develop a new product offering written in COBOL or PL/1?

Just because something is on life support doesn't make it alive. Pull the plug and let's see what happens...

A system, a diagram, a document or other artifact with no conceptual integrity often becomes an amorphous blob of human insensitivity. This also happens when an artifact grows rapidly with no refactoring. Some times too much ill-conceived or bad refactoring can turn a previously decent idea into an amorphous blob. It is sometimes facilitated by managers that use engineers as little more than interchangable parts. As a result, the software, its documentation or concepts at large has no more continuity or definition than the team has itself...



The Borgification of IT seems to occur in companies whose management team seems to recognize no shades of gray in talent or experience for non-managers and non-team leads. I'd like to think that even more than shades of gray in engineering, that there is a vertical career path that could parallel management without having to go through management. Something like an architectural path leading to Chief Architect or some such. Maybe making a move into R&D, shaping the technological agenda or making more strategic road map decision on product-line.

The Borg mindset of utter consistency almost always results in human insensitivity. Whenever artifacts include everything that recklessly has everything but the kitchen sink in it, even when it doesn't, you end up creating one. One of the more sinister practices in the creation of guides that are supposed to guide practitioners to a solution. Has anyone ever wondered why there are so many guides in problem domains such as data and security yet enterprise security and data quality in measurable terms are on the decline?

Visit the Microsoft Developer Network site (MSDN) and observe how they describe the problem domain of authentication and authorization. Did you note that the resulting API libraries are well-documented but otherwise are particularly insensitive to any conceivable user? Did you notice how problem domains where documentation are the focus are exacerbated when trying to use them from .NET, Ruby on Rails or some other modern language?

Has staff turnover, aggressive schedules and the desire for scripted changes aided in keeping things simple or simply resulted in a blob of human insensitivity? Despite what we hear, all engineers are not interchangeable. Two people can be in the industry for the same length of time and have widely different ranges or depths of experience. Is it a best practice to ignore the unique experiences of members of the team and instead strive for human insensitive homogenization?



Let's pretend for a moment that you are a project manager within an large enterprise setting and you work for a boss that refuses to allow you to do one thing really well and instead prefers to give you multiple assignments. You face the challenge of managing two projects, both of such a high priority that you cannot assign an engineer to one of them and ignore the other. You somehow think that you are brilliant in assigning the engineer 50% to one project and 50% to the other and declare that this makes excellent use of the engineer's time. People can easily devote exactly four hours of thought per day to one project, and four hours to the other. And if there are three high-priority projects, assign the engineer 50% to project A, 50% to project B, and 50% to project C.

A real engineer will eschew such sage wisdom human insensitivity and will normally work one of the projects and ignore the other. Parallel task lines on a schedule look nice and they save you, as a manager, effort in explaining why something has not started yet, but parallelism does not get the tasks completed any sooner. Serialization is the most efficient use of resources to get the projects completed in the least amount of time. Being full time on a project is almost always better than being split - unless you're stuck or waiting on somebody else. When you're full time then the project gets your "shower thoughts". By working one to completion and then the other you finish on average ahead of when you would have with a parallel approach.

Increasingly, the gap between the values of employees and employers is growing larger. Managers will either use weapons to beat their employees into submission while leaders will find ways to create win/win situations...



There are situations where the ‘beliefs/values’ of individuals are in conflict with those of the business enterprise to the extent that they cause business problems.

For example, imagine a retail pharmacy chain where some individual pharmacists ‘right to life’ beliefs/values causes them to refuse to sell prescription birth control medication. From a business standpoint this is unacceptable. In this sort of situation it would not be appropriate to attempt to ‘realign’ the values of the individuals. Management would need to find some other solution.

A manager could make a bad decision out of ignorance, threatening to fire the employee or they could step up to leadership thinking and figure out a few alternatives. One potential solution may be to staff the pharmacy with two pharmacists (provided the workload supports it) and ensure that non-offensive work gets routed appropriately. Another solution may be to encourage the customers that use birth control to purchase it via mail order. The customer gains convenience while the pharmacists remains productive in his/her discipline and it becomes a win all the way around.

Leadership is a game of thinking where you are always looking for a better way to make your employees (followers) happy. If you are simply attempting to make them conform, you have lowered yourself to a manager...

There are lots of definitions for enterprise architecture and over time, people attempt to further refine its mission by adding on additional overhead while avoiding pragmatic thinking...



The United States Government, Office of the CIO defines enterprise architecture as:

A strategic information asset base, which defines the business, the information necessary to operate the business, the technologies necessary to support the business operations, and the transitional processes necessary for implementing new technologies in response to the changing business needs.

Doesn't this sound freakin expensive? I have stated in the past that Government Enterprise Architecture is a big fat joke! In order to realize this definition, one must establish a culture that:

• timeframes not counted in weeks or even months, but in years needed in order to perform a comprehensive analysis.


• The large number of highly placed internal staff that become absorbed by the process.


• The army of expensive consultants that are necessary in order to navigate through the complex methodologies.

Should the success of enterprise architecture really depend on the ability of a consultant to articulate the differences between TOGAF, Gartner, Zachman and hundreds of other frameworks? In Corporate America, there are lots of people successfully doing enterprise architecture and adding value to their business who haven't even read one iota of an industry framework.

Should the success of enterprise architecture require lots of process weenies ensuring that everyone has their number two pencils sharpened and that all TPS cover sheets are completed? Wouldn't the sign of a more mature EA discipline have less process than more?

The army of expensive consultants who spend time creating pretty documentation in various forms in order to satisfy contract deliverable is also wasteful in that the documentation doesn't actually help improve anything. At best, you can record current state, but everyone knows that SNAFU rules.



So, if the goal of an enterprise is not to completely document every business process, every software system, and every database record that exists throughout the organization, but instead to find opportunities to use technology to add business value, then what have we been doing all these years?

If adding business value is not the ultimate goal of an enterprise architecture, then the energy put into creating that enterprise architecture has been badly misplaced.

Another travesty is when enterprise architecture borrows from the building trades. The notion of the city plan which governs what types of buildings will be permitted in a community is appropriate. However, your local town hall has realized that it is NOT in the business of drawing blueprints and this task is best left distributed. Imagine a city that included in its city plan a detailed blueprint for every building that would ever be built in the city. Such a plan would be extremely expensive to create, and, if it was ever completed, it would be inflexible and stifling.

My 2011 thinking says that in order for enterprise architecture to improve we need to stop the practice of defining and work tweaking and instead focus on values. The Agile Software Development community allows for people to practice Scrum, XP, Kanban or any other Agile method without concern. Regardless of the methodology chosen, they all encourage you to adopt an Agile mindset based on Agile values.

Now for a trick question, what are your organization's enterprise architecture values?

Way too many people I know are stressed about work, life and family. You don't have to learn just to live with it and if it is work related, there are a few things you should ask your employer to consider...



If you are feeling stressed in a given situation, why not ask your employer to deploy you in a less stressful situation. Most employers are reasonable and want their employees to be happy and will consider allowing you to be productive while working elsewhere. I have yet to meet an employer that wouldn't consider this.

A healthy dose of laughter and a sense of humor - I read that a child laughs 400 times a day on the average, while an adult laughs only 15 times each day, which is puzzling since laughter feels so good and is so good for us! Many of us have lost our humor beings. Everything doesn't need to be so serious. Consider telling jokes during the day regardless of political correctness as the increase in productivity will have a profound return.

Hugging is practically perfect: there are no movable parts, no batteries to wear out, no periodic check-ups; it has low energy consumption and high energy yield; it is inflation-proof; it is non-fattening; it requires no monthly payments and no insurance; it is theft-proof, non-taxable, non-polluting and, of course, fully returnable. Of course, make sure you don't hug your coworkers too frequently especially if they look like Sophia Vergara, Melyssa Ford or Halle Berry as productivity will decline and stress will increase...

Many industry analysts have worked in the past for large enterprises in the capacity of Architects and CIOs. I did some analysis to figure out why they became industry analysts...



A quick search using LinkedIn shows that the majority of people who leave enterprises to become industry analysts never return. A happy perspective says that they are interested in opening new doors, while a more pragmatic view says they are attempting to close a few doors as well. So, in order to understand this perspective, lets first take a look at what new doors does it open.

Whenever an industry analyst leaves their firm, there is a high affinity to going to work for a software vendor. The role they take on tends to be very strategic in nature and usually involves figuring out how to one-up the competition. In this role, they don't necessarily lose the benefits of becoming an industry analyst such as attending industry conferences but do get to scale back on travel somewhat.

In terms of the door that the industry analyst closes when they depart from working for large enterprises is the bureaucracy. Analysts don't have to expend as much energy on perception management as say an Enterprise Architect. Likewise, they only focus on strategic issues where an Enterprise Architect may get drawn into less desirable efforts such as outsourcing or even production support. The ability to have a job that is 99% strategic can be much more rewarding.

Let's face it, jobs that involve operations tend to result in long hours in order to make little progress. Being so connected and awaiting the phone call for the next crisis is simply tiring and for most people with Architect backgrounds, downright boring. Independent of being able to escape operations along with also not having to focus on perceptions, analysts get other rewards.



In my mind, I think there is a huge difference between travel and commute. For purposes of this blog, we will separate the definitions based on when the clock starts. For example, if you are a sales engineer working for RedHat and you live in the Hartford CT area, you may need to travel to New York City to do a presentation at 10am. So in order to make it there on time, you leave your house at 7am. Once you are done with the presentation you decide to visit a few other folks in the city and return home early while doing work on the train. This is travel. Now, imagine you are an Accenture consultant having to get on a plane and fly to Newark to visit an insurance client. The time spent getting from one place to another comes out of your personal time as the clock doesn't start until you arrive. This is commuting.

So, analysts do a lot more in the way of traveling while the rest of the world does a lot more in the way of commuting. when an analyst gets on a plane, he/she is probably going to meet new faces each and every week, whereas the lowly Accenture consultant traveling to Newark is going to meet/interact with the same people this week, this month and so on.

Many analyst firms have a work from anywhere policy. Ever notice when you are having a scheduled dialog with an analyst, you never really have a clue as to where they are located? Even for very progressive enterprises, they still haven't caught up to the level of maturity that are afforded in the world of industry analysis. For example, if an enterprise let's their employees work from home, home is a literal destination. Industry analysts are afforded a level of autonomy that simply doesn't align with enterprise thinking. Imagine a restless industry analyst who for whatever reason, gets tired of sitting at their desk at home. They can simply pick up their laptop and phone and go sit in Starbucks and work. An analyst isn't required to tell his/her boss about this and on the remote chance they did, it would be viewed as an annoying form of communication because no one actually cares. Contrast this with most enterprises that want to physically know where you are located during core working hours.



If you work in a large enterprise, you are more than likely performing a few tasks that probably doesn't fit your job description. Let's refer to this as a Hobby job. Sometimes, being physically available causes one to be assigned misc tasks. While it is possible that an analyst could be asked to do something strange by one of their clients, we know that in a model with very high bill rates, tasks that aren't truly strategic will be short-lived. Sometimes, affordability causes its own challenges.

Have you considered the fact that in becoming an analyst, your employer is actually going to commit significant resources to personally branding you? when was the last time your boss ever said he wanted to spend time making you look good? Analysts thrive on brand and it is in the best interests of analyst firms to expend lots of energy branding their employees. Enterprises on the other hand, can view their employees simply as human resources that can be leveraged any way they see fit. Analyst firms truly understand that people are its most important asset, a concept that is lost on most enterprises...