Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

The People Problem: A Primer on Architecting the Enterprise as an Enterprise Architect
The People Problem: A Primer on Architecting the Enterprise as an Enterprise Architect
The People Problem: A Primer on Architecting the Enterprise as an Enterprise Architect
Ebook245 pages3 hours

The People Problem: A Primer on Architecting the Enterprise as an Enterprise Architect

Rating: 0 out of 5 stars

()

Read preview

About this ebook

Your business is solving the wrong problems.

The nuclear triad of People, Process and Technology has been foundational to solving business problems for decades. Entire frameworks and methodologies have grown up around the simple concept that getting each of these three areas correct and functioning in concert will ensure smooth business operations and cross-enterprise alignment. Billions of dollars have been spent on people in the management consulting industry who have "mastered" the art of alignment and offered definitive solutions to the biggest, wickedest business challenges out there. And yet... our businesses continue to encounter the same well-known and seemingly well-solved problems, spending massive sums to fix them. How can this be?

It is said that modern business is one part innovation and one part marketing. Innovation is often mistakenly equated with technology and marketing with 'digital'. Success in business therefore becomes a chase for digital capabilities and the latest technology to enable them. And yet… the latest technology continues to give us problems, create headaches and doesn't always give our businesses the edge they need to compete, despite costing us huge amounts of money. How can this be?

The reality, of course, is that businesses are chasing the wrong buzzwords, buying the wrong solutions, solving the wrong problems.

The People Problem tackles this topic from the perspective of Enterprise Architecture. For newcomers and open-minded old-timers who practice EA, architecting the enterprise is all about asking the fundamental question 'what business problem are we trying to solve?' When practitioners pay close attention, they'll recognize that business problems are infrequently solved by a new tool. That is, Technology isn't the answer to the problem. They'll also notice that the most efficient process in the world, made popular by the flashiest buzzwords in the industry, is insufficient to answer the fundamental question. In other words, Process is not the answer to the problem. Human beings are at the root and core of our businesses. They define the processes and operate the technology. Only by recognizing that solving business problems requires solving problems with (and caused by) people will we get close to the right solutions.

The People Problem aims to help new entrants to the field of enterprise architecture (and anyone interested in solving difficult business problems) navigate in an era of particularly rapid business and technological change. Based on over 17 years of experience consulting with companies large and small, Fortune 500 to local startups, The People Problem is a collection of accumulated knowledge presented in easily digestible vignettes.

Discover The People Problem in your enterprise today and get a halfway decent start at addressing the critical issues facing your business.
LanguageEnglish
PublisherBookBaby
Release dateNov 13, 2017
ISBN9781543914917
The People Problem: A Primer on Architecting the Enterprise as an Enterprise Architect
Author

Chris Lockhart

Chris Lockhart has a PhD in medical anthropology from the University of California, San Francisco, and UC Berkeley and is the coauthor of Tupa Tjipombo’s I Am Not Your Slave: A Memoir. He has worked across Africa as an independent researcher and consultant on a variety of development projects in the areas of global health, human rights and journalism.

Related to The People Problem

Related ebooks

Business For You

View More

Related articles

Reviews for The People Problem

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    The People Problem - Chris Lockhart

    problem.

    THE WRONG BUSINESS

    1. WHY TALK ABOUT EA?

    I was an enterprise architect before I knew what the term meant.

    I just didn’t fit in with all the other late 90’s start up hotshots. I wasn’t a developer (unless you include html and flash, which I don’t). I wasn’t a network techie. I wasn’t a DBA. I wasn’t a business analyst. I definitely wasn’t in sales or marketing. Frankly in the world of a 5-man internet start-up, there isn’t much room for anyone else. I was just the guy who was always trying to figure out how our technology matched up with the stated need. In short, I spent my start-up years wondering why anyone needed the things we were coming up with.

    What problem is this solving?

    A room full of 20 year olds hyped up on Dew and coffee with angel investor dollar signs in their eyes weren’t interested in hearing that question. In the second half of the 1990s, it didn’t really seem to matter what you were producing so long as the hype was sufficient to garner buyout attention. And trust me, that worked (for a while). I thought I was going to retire forever.

    What business value does this technology provide?

    Another question met with bewildered stares. When frenzied, iterative development and flowing, constant delivery of features is the drumbeat, the need to assess the solution within the context of the business is not high on the priority list. Well, if you lived through the dot-com bubble in the 90s, you know how that worked out.

    You don’t have to fit the mold.

    I entered corporate America and was thrust into a role where I had to be scrappy. I managed firewalls, LDAP servers, web servers and application servers. I was part of a team of folks who had an instinct for how systems had to be assembled into solutions to address requirements conjured by the development teams. I say requirements in quotes because the reality is there was very little in the way of formal methodology. It was more along the lines of hey I need to be able to hit MQ server number five and so we made it happen. The difference here was that when we made it happen, we did it in a coherent, planned, methodical way and we developed a sense of strategic direction with our planning. We aligned our technical machinations with perceived and anticipated changes in the business. Keep in mind we rarely ever talked to the business, let alone knew who they were.

    So, we began calling ourselves architects.

    In the structured, nurturing, cash-rich environment of Fortune 100, it is easier to talk in the terms familiar to architecture. Terms like governance, requirements, capabilities, domains, logical, conceptual and… oversight, all have much more meaning and real-world impact in such an environment. There are boards of review and approval committees and various needs of various fiefdoms for input and credit. If architecture and strategy didn’t exist, they would have to be created to make sense of Fortune 100 IT. The problem, of course, is the stifling and oppressive nature of such organizations. They didn’t, at this time, provide much room for the innovator to work his magic. What is IT architecture if the conditions stifle innovation?

    It wasn’t until later, when I was a consultant, that I realized we had been doing proto-EA work during this time. Given the constraints imposed by a badly-run business and a sort-of inept approach to technology, it wasn’t possible for us to truly conduct an EA program at that time in that company, nor would we have known how if we had even recognized the need. The silos were in full effect and there was simply no way to engage the business without pissing a bunch of people off higher up the chain. So, we muddled along doing the best we could in a mostly reactionary manner.

    There was no champion.

    Consulting provides a window into the world of companies. If architecture was a college course, consulting would have to be a required internship. We learn by doing and there is no better way to do than to do at many companies in many industries, succeeding at some and failing at others. Each company is different but has similar qualities and patterns begin to emerge if you consult for enough time. It was not as a technical consultant but as a management consultant that I learned one critical key to EA that I had never fully appreciated: the champion. I discovered a pattern in EA programs across many different companies. It isn’t rocket science: Without someone in a position of power and/or holding the purse strings behind you, any EA program runs the risk of being relegated to the role of a lofty thought experiment. This was my experience in industry.

    It’s just as important to learn what doesn’t work.

    One of the ironies I always think about is how I started as a technologist and ended up being almost an anti-technologist. Technologists are hard-wired to see every problem as one that can be solved with a tool. It is instinctual. The reality of course is that most problems I have ever encountered were hardly ever a problem with technology. Most problems end up being a people problem. Yes, tools are a Godsend for solving problems, for automating things and making solutions easier to implement and manage. Tools enable success, in many cases. But the problem was rarely in the logical or physical views, the domain models or conceptual models; the reference architecture itself was hardly ever really fought over. In fact, as highly paid technology and management consultants, we often joked that we knew the future state as soon as we heard the business problem. The artifacts themselves wasn’t where the value was. The value was in understanding the complex web of relationships between the people and the things that they do when they work. The value was in instinctively knowing, in your gut, the right direction to go in aligning the technology with that complex web of relationships. Failure was (is) common. It isn’t because the technology is crap, it is because as an architect, an Enterprise Architect, you are dealing with the most complex system of all: people. Knowing human beings is perhaps one of the most critical foundational skills of a good enterprise architect.

    The industry might just be wrong.

    So why talk about EA? Well far be it from me to suggest I have knowledge that the industry collective does not. I don’t, no one can. But I do want to spend some time relating some of the things I’ve learned about working with enterprise architecture because I don’t think the story is told well enough or often enough. There are notions of this field out there that I think are flat out wrong. There are far too many people running around calling themselves enterprise architects with no clue what it actually means. I think the IT industry itself does a poor job understanding the needs of its most important customer, the business. Quite honestly, I think the industry might often be wrong.

    2. WHO NEEDS A VISION ANYWAY?

    Paging an IT Leader.

    One of the things a good IT leader always needs to ensure he or she understands is basically what it is they’re trying to do. Sounds simple. But the day-to-day of IT operations and business-as-usual activities can sometimes overwhelm leaders with arcana and impair their ability to see where they’re going. Pretty obvious and in truth this is a great thought exercise for a CIO forum or workshop.

    Imagine, however, the folks who work for the befuddled IT leader. If he doesn’t really know what he’s trying to accomplish, odds are pretty good that his reports have no clue. Sadly, there’s no forum for confused underling architects to work out how to divine the mission, vision and goals of an organization.

    Being squishy is good.

    I’ve described the process of knowing what you’re doing as consisting of ‘squishy’ things like vision or mission statements. I call them squishy because of how inconsistently things like vision are described and applied. Forget how subjectively they’re communicated and understood. Sadly, they are usually thought out with great energy, written in a Word document and then forgotten by everyone until there’s a reorg and it’s time to update it. A bit cynical maybe, but true.

    The vision is important. The purpose of the organization and its mission are critical to get right. Without it, how do you know what your objectives are? How do you know what you’re doing? How do you measure your activities? How do you know you’re being successful? How do you know you won’t be reorg’d into the unemployment line?

    Where’s the value?

    Sure, you could measure things like ‘utilization’ or ‘billable time’. But those are merely metrics that represent progress toward some thing. The thing has got to be a concise and discrete objective with milestone goals identified. I don’t mean a change request number or GL code that you use in time keeping each week (or each day in some micromanaged organizations). I mean a clear statement of purpose and a defined path to achievements that serve that purpose.

    At some point everyone gets to a place where they ask themselves what value am I providing to the organization? How is spending my time on this valuable? If there isn’t a way to tie your daily activities to some set of goals and objectives that in turn are tied directly to some greater purpose, you are in trouble. The first thing that happens is morale tanks. Secondly, people will start asking (especially at budgeting time) what it is your team actually does. Your folks will spin their wheels doing work that serves no purpose and is of no value to anyone. Lastly, they’ll either leave, get themselves fired or get you fired. Millions of dollars will have gone down the drain in the process.

    Nah, this never happens.

    We all know some organizations that fit this mold. There are units and fiefdoms within every major organization consisting of human beings where purpose and value are lost in a fog. These are the groups that seem to be on every call, in every meeting. They have fingers in everything because they have no objectives, no purpose. They’re casting about for busy work to demonstrate how important they are and to fulfill a need for self-worth and self-valuation. They usually have big plans that flash in the pan and then dissipate in an atomized cloud of confusion and insignificance. Most other groups end up ignoring them.

    It doesn’t have to be this way. Wouldn’t it be easier to clearly define your raison d’etre up front? Use whatever framework you like. Map your vision. Define the mission of the team that will work to realize that vision. Identify and clearly delineate the objectives of the organization that serve the mission. Figure out what goals or milestones exist for the team to work toward to reach the objectives that advance the mission.

    Getting there.

    Unfortunately, many IT leaders don’t possess the soft skills necessary for this kind of work. But if the IT leader knows what he’s doing, if he can clearly and concisely define and communicate the plan to the team, the team should have no problem figuring out how what they do daily provides value to the enterprise. People will be happy, productive and rewarded by meeting goals to reach objectives that serve the mission to realize the vision.

    3. RESPONDING TO CHANGE: EA & AGILITY

    When you read this, read it aloud and try using air quotes in real life wherever you see me use double quotes in the text. It’ll be more puzzling, exasperating and/or amusing that way.

    I was having a conversation the other day with a colleague. The topic was a particular project that wasn’t moving very quickly due to issues understanding in clear detail the nature of the business problem. This colleague said, we really need to institute some agility here.

    I’ll give you a moment to digest.

    This colleague was implying you could basically just pick up agility and, you know, start doing it. It’s almost as if he believed that the entire concept was as simple as a 12-step program in a self-help book or an installable runtime from github. Agility isn’t something you randomly insert into a project whenever it seems to be incapable of responding to change or runs into trouble. Nor does agility speed up the regular SDLC if agility wasn’t there to begin with.

    After that conversation, which by the way ended with the colleague exhorting my enterprise architecture team to do something about the lack of agility, I Googled agile architecture and got some interesting results:

    •Business Agility using ArchiMate with TOGAF

    •Agile Architecture: Strategies for Scaling Agile

    •Agile Architecture – Scaled Agile Framework

    •Agile Enterprise Architecture

    •In Search of Agile Architecture

    The colleague also referred to himself as a scrud master so I guess I shouldn’t have been surprised. But I digress.

    Isn’t EA already agile?

    You can try different Google search combinations of agile and architecture and business and agility, etc. The results are often similar. Parts of the Interwebs believe agility is a methodology, a framework, a tool. I suppose the inherent difference is between Agile and agile, or Agile and agility. That is, the commercialized lifecycle management approach complete with certifications and books and whatnot, versus a state of being. I contend you’re either agile or you’re not. Regardless of whether you use Agile or not.

    There is also an accompanying viewpoint in many of those search results that Enterprise Architecture as it is practiced follows TOGAF or Zachman or what have you, and is inherently vertical and top down and therefore can be made agile by using Agile. The suggestion appears to be that agility can be modeled in the same sense that EA is depicted. I understand the need to have pretty diagrams and charts within your architecture framework that attempts to model EA and its practices. Think FEA’s three-dimensional cube – very pretty to behold. But even so, it seems to me that being agile isn’t simply a matter of looking at a colorful chart of boxes and arrows and using Agile.

    I think the disconnect comes down to a fundamental misunderstanding about what it means to be agile. Agility isn’t about simply speeding up a development lifecycle or making things move faster in general. If it were, it’d be called Speedification or perhaps Fastiness – I’m still taking submissions. It is almost like confusing speed and velocity. No agility isn’t always about speed. Agility is about possessing the ability to rapidly and nimbly respond to change. That change could be business, technology, market conditions, macro-economic, personnel or an act of God. A response to change may, in fact, be a response that temporarily slows things down as efforts are re-oriented. The point is being able to clearly identify the offending change and execute a response strategy based on the changed conditions to seek some advantage from the change (or at least prevent the change from negatively impacting your business).

    It is called ENTERPRISE architecture.

    EA is aptly named. It isn’t vertical only. It is by its very nature both vertical and horizontal. It is all-encompassing. EA is omnipresent. It should be called OA.

    EA doesn’t institute or do agility and while it is compatible with Agile, it doesn’t mean that if you use Agile that you will be agile. Also, let’s be clear: you can’t buy agile in a product. But when adopted and executed properly, EA helps structure an enterprise so that it can move with

    Enjoying the preview?
    Page 1 of 1