Todd Biske: Outside the Box

Archive for the ‘IT’ Category

A key to any Enterprise Architecture program is solution architecture. Solution architecture is where work gets done. If your EA team is disconnected from the solution architecture effort, you’ll probably hear the term “ivory tower” a lot. Unfortunately, it’s far more common than you may think.

Looking the typical project, the first question is where do the solution architects report? Since many times they have grown out of senior development roles, odds are they don’t report into the enterprise architecture organization. On top of that, the key authority figure (decision-maker) within the project structure is typically not an Enterprise Architect, and it’s not even the solution architect’s manager. It’s the project manager and the project sponsor. This leaves a whole bunch of people that need to be influenced. They are:

• The Solution Architect
• The Solution Architect’s Manager
• The Solution Sponsor
• The Project Manager

The Solution Architect. The solution architect is going to get pulled in different ways. I believe that it is the job of Enterprise Architecture to make the solution architect’s life easier, rather than more difficult. If you’re just another voice pulling them in a different direction, it’s not a good situation. Think of yourself as a mentor to the solution architect, and provide them with the tools they need to do their job. Those tools are excellent reference material in the form of standards, guidelines, and patterns, pointers to the right people to talk to, a sounding board for options, and another set of eyes for reviewing work. On top of that, you should consider whether or not solution architects should report into the EA organization, or at least have dotted line reporting structures into EA. Which leads to…

The Solution Architect’s Manager. Assuming solution architects don’t report into EA, someone else is writing their performance review, and odds are, they’re getting judged not on the quality of their architecture but on their ability to deliver. They should be judged on both, and it’s up to the Enterprise Architecture team to work with the solution architect’s manager to ensure their performance objective include architectural objectives. If you don’t, architecture is likely to lose when push comes to shove. Also, keep in mind that you need to have regular conversations with the managers of the solution architects. Odds are they have regular conversations with their business stakeholders, who in turn influence the work that gets done. EA needs to have similar influence.

The Solution Sponsor. This is a challenging one, but very important. It’s challenging because in many organizations, IT relationships with the business are considered protected turf, and people can get really bent out of shape if you have these conversations without them there. I think we need to stop protecting these conversations and instead start encouraging them. If it can help the company deliver better solutions, then get the right people talking to each other, period. What’s really important with the sponsor is to start talking about the architecture of the effort before the funding proposal is made. If you can bring the solution architect with you, even better, because that will build rapport. Make the sponsor aware of the needs of the enterprise, work to get their support, and then when you need to make decisions within the project, the person at the top of the decision making chain should have awareness of not just the financial and schedule needs, but also the enterprise architecture needs.

The Project Manager. Finally, it’s the project manager. If you’ve properly influenced the sponsor and the solution architect, this one shouldn’t be a problem, but we shouldn’t ignore the project manager. It is their job to make sure the right things get delivered. The solution architect should be their partner in the effort, helping them to know when things are going off track from a technical perspective. There are delivery requirements, functional requirements, and architectural requirements, and the PM has to make sure all three are addressed. It is better to discuss the relative priority of each of those up front, rather than deal with the contention in the middle of the project. Will you allow the schedule to slip to maintain the right architecture? Will you sacrifice functionality for the right architecture? Talk about this before it becomes an issue. Also, if you have a formal review process, make sure the PM knows what is needed and what questions are going to be asked. They want the review to go smoothly, so you have to give them the tools they need to know when they’re ready to be reviewed and to pass without any issues.

Hopefully you’ve found this focus on solution architecture useful. As topics come up under this theme of architecture by influence, I’ll have additional posts. If there are specific questions or challenges you have, feel free to send me an email or post it via a comment.

This is a first in what I hope will be a few blogs around the subject of architecture by influence. There are no shortage of people who are writing that enterprise architects can’t be successful unless they have some teeth, i.e. the ability to stop activities in their tracks that aren’t compliant with the architectural direction. There’s also no shortage of people who have written that architecture by mandate doesn’t bode well, either. You’ll either never have that mandate (i.e. no teeth), you’ll leave so many dead bodies in your wake that morale will take a precipitous decline, or the first failure will be blamed on the mandated architecture and the team will be disbanded, or worse, fired. Well, my goal with these posts is to get away from these “what’s wrong with EA” posts and to start the conversation on ways we can make it work.

In order to do this, we first need to talk about the decision making process, which is the focus of this talk. If you don’t understand how decisions get made, you can’t hope to have systemic success with your architecture program, let alone your solution delivery efforts. How many times have you been on a project where meeting after meeting is happening and you just want to stand up and scream, “someone make a decision” It’s usually not for the lack of ideas, it’s usually because it’s unknown who has the authority to make the decision. In the early days of my career, I saw this all the time when a project had a project manager, but had no stated technical leadership. The team would look to the only hierarchy they had- the project manager- but the project manager lacked the knowledge to make good decisions. It’s the project manager’s job to make sure decisions get made, but the scope of decisions they’re normally trained to handle is schedule and resource management.

So, step one is to first understand who has the authority to make the decisions. If it’s unclear, clarify it first, don’t just bring everyone into a room and try to make decisions. There’s nothing worse than having a bunch of people in a room who think they have the power to make a decision, when they really don’t. That’s when things can get very ugly. Often times, the winner is not the person with the right idea, but rather the person who has the most domineering personality. Another common trend is that it is the person who holds the checkbook. For decisions that involve spending money, this is frequently the case. If funding is not in question, then this person may not be involved. Even worse, they may get escalated to this person (because they’re seen as the top of the food chain), at which point credibility erodes because they are likely to say, “What am I paying you people for? It’s your job to make those decisions.”

So, the next question is, how do we avoid personality-based or bias-based decisions? It’s human nature to fall into this trap, as we’re bombarded by it in virtually every facet of our life. The way I’ve found that works, and simply stated by a former boss of mine, is to get the decision criteria out on the table and get everyone to agree on it. If you’re worried about internal expertise, make it part of the decision criteria. If you’re worried that integration challenges will exist down the road, make it part of the decision criteria. Not only does this allow people to check their biases at the door, but it also gives the necessary context for people to actually present their options. If you don’t know what you’re being evaluated against, how can you hope to be successful?

This is one of my personal pet peeves when it comes to architecture reviews. Too often, the guidance for a team undergoing an architecture review is nothing more than, “you have to have one or more of these people that we believe are smart look at your architecture.” How can a team have any idea on what things are important to that reviewer or review board? They make their best guess, and then the whole thing dissolves into the reviewers trying to show that they know more than the team by finding something that was overlooked (and there’s always something) or opening up debate on other options, regardless of whether or not those options actually make any difference in what is going to be delivered. Again, it’s setting people on a path toward frustration, rather than setting them up for success. To be successful, make the team aware of what things they will be evaluated against up front, give them a framework for which options can be presented rather than an all or none checkpoint approach, and keep the focus on delivering the right thing, rather than on wielding power.

So, to summarize, here are the guiding points for analyzing your decision making process:

• Figure out who has authority to make decisions. Different people can handle different decisions, but you really want one person with the final call.
• Define the criteria for which options for each decision will be judged. Check your biases at the door. Make sure to prioritize those criteria, as well.
• Present options for the decision involved, and evaluate each option against the criteria. Avoid “I don’t know” for any criteria. If the criteria are known up front, there’s no excuse for not doing the analysis of your option against those criteria.

For some, this post may fall into the “stating the obvious” category, but at least based on my own personal experience, far more important decisions are made by personal bias or opinion than by this approach. You can make a career by having good decision-making ability, but all it takes is one bad decision to have it all come tumbling down. With a more fact-based decision making approach, it’s easier to see where the failure was due to poor, incorrect, or incomplete information supporting the decision rather than a poor decision maker.

On Twitter, Brenda Michelson of Elemental Links started a conversation with the question:

Do #entarch frameworks enable or constrain practice of (value from) enterprise architecture?

In my comments back to Brenda, it became clear to me that there’s a trap that many teams fall into, not just Enterprise Architecture, and that’s falling into an inward view, rather than an outward view.

As an example, I worked with a team once that was responsible for the creation, delivery, and evolution of data access services. Over time, teams that needed these services were expressing frustration that the services available were not meeting their needs. They could eventually get what they needed, but in a less than efficient manner. The problem was that the data services team primary goal was to minimize the number of services they created and managed. In other words, they wanted to make their job as easy as possible. In doing so, they made the job of their customers more and more difficult. This team had an inward view. It’s very easy to fall into this trap, as performance objectives frequently come from internally measured items, not from the view of the customer.

EA teams that obsess over the adoption of EA frameworks fall into the same category. Can EA frameworks be a valuable tool? Absolutely. But if your primary objective becomes proper adoption of the framework versus delivering value to your customers, you have now fallen into an internal view of your world, which is a recipe for failure.

Instead, teams should strive to maintain a service mentality. The primary focus should always be on delivering value to your customers. There’s a huge emphasis on EA becoming more relevant to the business, in order to do so, we need to deliver things that fit into the context of the business and how they currently make decisions. If we walk in preaching that they need to change their entire decision making process to conform to a framework, you’ll be shown the door. You must understand that you are providing a service to the teams you work with and helping them get their job done better that they could without you. While a framework can help, that should never be your primary focus. Internal optimizations of your process should be a secondary focus. In short, focus on what you deliver first, how you deliver it second. If you deliver useless information efficiently, it doesn’t do anyone any good.

Pardon the Phineas and Ferb reference, but when I read this post from Chris Lockhart, I couldn’t help but think of Professor Doofenschmirtz and his inventions. I really liked this post from Chris and how it emphasizes understanding the nature of the problem at hand. I’ve had first hand experience at more than one company where people had solutions without a clear idea of what problem it was going to solve (ESB anyone?).

A description that I’ve used before is to talk about the left and the right hand side of the equation. It is the architect’s job to understand both sides and find the match between them. The technology available to you is the right hand side. The capabilities that need to be provided (or the problems that need to be solved) are the left hand side. There are plenty of things that can go wrong. For example, if you only have one thing on the left hand side, “I need an application that does this,” it’s too coarse grained to map to any single thing on the other side, and now it puts you at risk of just choosing arbitrary technologies based on experience or preference rather than the capabilities needed. If you have multiple technologies that all map to the same set of capabilities, then you either have more technology than you need, or you haven’t defined your capabilities to the right level of granularity.

This theme gets back to the archivist versus activist discussion. If you only look at the technology side of the things, you become an archivist. You can’t be an activist unless you can adequately describe the problems and the capabilities that will be addressed by changes to the technology.

Great post Chris. To end on a Phineas and Ferb quote, “Mom, those enterprise architects are blogging again!”

While I’m not doing much these days in the BPM space, I did recently have lunch with a friend of mine who works for Genesys Lab. I don’t normally talk about vendor products by name, but the iWD (intelligent Workload Distribution) product had a different enough approach from things I’ve seen that I thought I’d share it. In the spirit of full disclosure, I’m doing this on my own time (and dime), simply because I thought the solution was interesting. Hopefully you will too.

In the past, the BPMSs that I dealt with (and the businesses trying to use them) were primarily focused on process automation and process management. Process automation tries to automate as many of the tasks within the process as possible. More importantly, the tools tried to put a process centric view around collections of tasks so that they could be more effectively managed. When successfully applied, these tools have delivered an increase in productivity, but there’s still plenty of room for more improvement. This is where iWD comes in.

iWD, as the name implies, focuses on the distribution of the manual tasks associated with business processes. It is not a BPM tool on its own, rather, it is solely focused on the distribution of tasks from your systems to the individuals that will execute them. Based on what I saw, you can think of iWD as a context-aware distribution engine. In some tools, a “worker” logs into the queue associated with a particular process and takes the next item off the queue. What if they’re not the most qualified for that task? What if there are other tasks associated with another process that are more important? What if customers have varying SLAs that cause one customer’s tasks to take precedence over another’s. By taking into account the customer and any associated SLAs, the skills and location of the workforce, and other factors, tasks can be distributed from across all processes to the global workforce in a more efficient manner.

Anyway, with context become increasing important in today’s systems, most commonly associated with location-based services, I thought this was a great example of using a variety of contextual items to improve the distribution of tasks in a BPM system. You can learn more by visiting the Genesys Lab website here. I’d love to hear other examples of context-aware computing, feel free to comment or send me a message.

A couple of weeks ago, I asked a simple question on Twitter: Should Enterprise Architects have/get an MBA? That meme made its way to InfoQ, so I figured I should actually post my own thoughts on the subject.

First, a full disclaimer: I don’t have an MBA. I do have a MS in Computer Science from the University of Illinois (go Illini!). At the time I got my Master’s, a friend of mine took a different route and did a combined MCS (Master of Computer Science)/MBA degree. In retrospect, I wish I had taken that route. Part of my reasoning to not go that route was the whole MCS designation. Who has ever heard of that? Even from an institution like Illinois, would anyone have known what it is? For those of you wondering, it’s basically a course-only option for a Master’s degree. Getting an MS required writing a thesis. Getting an MCS did not. More importantly, however, I realize now that my interests lie more in the application of technology than in the technology itself. I had inklings of it back then, but at that time, it was far more important to be strong in technology first, rather than the domains in which it was applied.

Today, it’s a different story. There are no shortage of tech-savvy people in the business, so simply being a technology expert is not going to get you as far as it did 20 years ago. I’ve seen enough headlines that say IT departments are shrinking, meaning that some of the technology knowledge needed is being provided by people outside of IT. I don’t think this trend is going to reverse itself, so those of us that want to make a career in the application of technology will increasingly need more business-savvy.

So, should we all go back to school and get MBA’s? I view it as a tool in your toolbox. It is not a guarantee of success, but it is something that can make the path easier. Having long term career goals and a clear idea on what it will take to achieve them is probably far more important. Some companies may look highly on MBAs in making personnel decisions, others may not. Those are all factors to consider.

The other thing I wanted to comment on is the fact that many (IT) people lamented that EA isn’t part of the MBA program. I don’t agree with this at all. It’s a business degree, and like it or not, EA is still viewed as a technology discipline, not a business discipline. I do believe, however, that MBA programs should include some aspect of technology management. If an MBA prepares you to be a CEO, shouldn’t you have some idea on what your CIO and CTO should be doing?

As for me, getting an MBA is on my radar, but I haven’t yet made a decision on it. I definitely am reading more business strategy books, and for now, I think that’s the right approach for me, as frankly, I’m more concerned about paying for my kids’ education than financing continuing my own. But if I were in college today, given what I have learned about my interests in applying technology rather than building technology, I would definitely take that path, combined with a technology degree.

Yesterday afternoon, I was involved with a discussion around EA 201x. The conversation began at a lunch meeting I had with Mike Rollings (@mikerollings) of Burton Group/Gartner, and continued on with Brenda Michelson (@bmichelson) of Elemental Links and fellow EA Chris Bird (@seabird20), among others. Near the end of the conversation, Chris asked the question, “Are Enterprise Architects really Enterprise Archivists?” Brenda responded that we really need Enterprise Activists focused on action, delivery, ideation, and evangelism.

The more I thought about this, the more I love the picture that is painted by this. An archivist is essentially a librarian, and unfortunately, there are probably many EA teams that fall into this category. I’m sure there are probably many CIO’s who also think this is exactly what EA should be doing: managing the list of approved technologies, standards, etc. That is a necessary activity, but is it really what your EA team should have as its primary purpose?

Now, think about the activist. Put aside any negative connotations associated with political activists and judicial activist, and focus on the pure definition, which is someone who engages in activism. Merriam-Webster defines activism as “a doctrine or practice that emphasizes direct vigorous action especially in support of or opposition to one side of a controversial issue.” So, enterprise activism, or enterprise architecture activism, should be direct, vigorous action in support of the architecture of the enterprise. Anyone who has worked in big IT also knows that there’s no shortage of politics and tension between enterprise views versus project views, strategic views versus tactical views, so I think it fits the “controversial” term as well.

Brenda’s comments about seeing action, delivery, ideation, and evangelism hits the mark.

• Action: The action is engagement. Talk to the people that have the ability to make change happen. Using the activism analogy, the EA is the lobbyist. Engage the stakeholders, and make your case.
• Delivery: Deliver the strategic architecture, and then work with the project teams to make sure the architecture is realized properly. If you’re only cataloging what other people have done, you’re an archivist.
• Ideation: Think about the future. James McGovern (@mcgoverntheory), a fellow EA, had posted once that EA’s need to have time to think. This is where the ideas come from, and then can get turned into the strategic architecture. They’re not the exclusive source of ideas, but EA’s are supposed to be your senior level thinkers, so innovative ideas should be expected of them.
• Evangelism: How can you be an activist without being active? Make the cause known. If the cause isn’t heard, work to understand why, and tweak the message accordingly.

Just writing this up actually has cause me to think about some things that I can improve on in my own role as an Enterprise Activist. While I doubt we’ll see this as a job title anytime soon, I think it’s the right vision, can help others understand the role, and can be a powerful motivator for the team.

Jeff Scott recently posted a blog listing 14 challenges faced by business architects. They really apply to any enterprise architecture practice, and I wanted to call out and comment on a few of them.

Lack of business skills in the EA team. I commented directly on Jeff’s post on this one. I am sure there are many EA’s that have heard this statement, the problem is that it isn’t actionable. What specific skills or knowledge is missing? If you can’t get a straight answer on this, be wary of the protectionist culture that exists in many organizations. This is even expressed in another one of Jeff’s challenges, “Gatekeepers protect their business relationships.” We should all be focused on achieving the business goals, but frequently our actions are more geared toward protecting turf and climbing the corporate ladder. Someone who refuses to tell you how you can improve may be guilty of this practice, whether done with intent or simply because that’s the culture. This is why you must follow the words of another Forrester analyst, Gene Leganza, and answer the question, “What’s in it for me?” (Forrester subscription required).

An approach I like to use is to always emphasize that I’m here to help. I’m not here to be the police force and a bottleneck, I’m here to make our outcomes better. If they have people performing functions similar to enterprise architecture, but perhaps called something different, don’t turn it into a turf battle because you will lose, assuming the group is having success with it. They’re already performing the function, so unless you have a way to make that function better, there is no impetus for them to change. One thing I’ve done in those situations is to turn the conversation around and get them to start sharing their practices with other teams, and offer to be the facilitator of that communication. That can certainly play to the ego of any protectionist, but it can also be a great asset for you in demonstrating the value of the practice of architecture. Remember, it’s more important to establish the practice than it is to establish the team. Otherwise, you’re just falling into the same turf war culture that everyone else does.

Another challenge Jeff mentioned is a culture of change resistance. The scenario I described above was one where no change was needed, because the practice was being done with good results. If the results are not good, change is needed. Prior to any discussion on how to solve the problem, you have to get agreement that there is a need to change. If you get that agreement, now you can have a solid discussion. If someone doesn’t agree on the approach, ask to come up with an alternative, because you’ve already reached agreement that something needs to change.

Of the rest of the challenges, there are two others that I wanted to call out, you can review the rest on Jeff’s blog. They are: “Business units plan and work in silos” and “Tactical business focus.” These two strike at the heart of my previous post on defining the enterprise first. If the business hasn’t recognized that there are certain things that must be addressed at an enterprise level, then clearly anything with an enterprise scope will be a challenge. These are cultural issues that may be outside of EA’s ability to address, yet they are huge impediments to a successful practice. My experiences indicate that it will take someone at an executive leadership level to make this happen. They must be interacting with the directors of those silos and the common leadership above. You may be able to get some things done at a grass roots level because some individual managers may be open to shared planning, but it’s hard to turn that into systemic change without help from the top.

Thanks to Jeff for collecting these challenges, I hope others will contribute to actionable guidance that can help overcome them.

In the Wired magazine article on the relationship between AT&T and Apple (see: Bad Connection: Inside the iPhone Network Meltdown), the author, Fred Vogelstein, presents a classic service management problem.

In the early days of the iPhone, when data usage was coming in at levels 50% higher than what AT&T projected, AT&T Senior VP Kris Renne came to Apple and asked if they could help throttle back the traffic. Apple consistently responded that they were not going to mess up the consumer experience to make the AT&T network tenable.

In this conversation, AT&T fell into the trap that many service providers do: focusing on their internal needs rather than that of the customer. Their service was failing, and the first response was to try to change the behavior of their consumers to match what their service was providing, not to change the service to what the consumer needs.

I’ve seen this happen in the enterprise. A team whose role was to deliver shared services became more focused on minimizing the number of services provided (which admittedly made their job easier) than on providing what the customers needed. As a result, frustration ensued, consumers were unhappy and were increasingly unwilling to use the services. While not the case in this situation, an even worse possibility is where that service provider is the only choice for the consumer. They become resigned to poor service, and the morale goes down.

It is very easy to fall into this trap. A move to shared services is typically driven by a desire to reduce costs, and the fewer services a team has to manage, the lower their costs can be. This cannot be done at the expense of the consumer though. First and foremost, your consumers must be happy, and consumer satisfaction must be part of the evaluation process of shared service teams. Balance that appropriately with financial goals, and you’ll be in a better position for success.

A couple of recent conversations have really caused this theme to spike in my head. In my experience, I’ve seen successful enterprise architecture and I’ve seen unsuccessful enterprise architecture. While many may put the blame on a failure to define what architecture is, I think that’s wrong. I think a recipe of failure is a lack of understanding of what the enterprise is. By that, I mean a lack of understanding of what capabilities should be managed at an enterprise level and what capabilities should not. There’s no uniform right or wrong approach, it is highly dependent on your company’s operating model as articulated in the book “Enterprise Architecture as Strategy.” In that book, the authors even state that at one extreme, a completely diversified company may have no enterprise architecture at all.

Once you understand what “enterprise” is, you have to set up the organization, processes, and governance to support that. To illustrate this point, however, let’s look at the differences today between two commonly “shared” organizations: HR and IT. Most big organizations have a centralized HR department. While I’ve never looked at the funding model for HR, my guess is that there is some overhead tacked onto every employee and every contractor that winds up paying the costs of the HR department. It’s a shared cost. One organization is normally not able to throw extra money in the pot and fund extra recruiters or benefits managers for their organization. Contrast this with IT where that’s exactly what happens. While IT may be centralized, it’s funding model is not. This results in IT organizations whose structure mirrors the business silos, and whose actions are completely controlled by the funding provided from each of those silos. What’s the point in having a central organization? That central organization really can’t dictate priorities or approaches, because someone else controls the purse strings. The right way of handling it is where the IT leader meets with the business leaders, they jointly agree on IT priorities and budget, and then the centralized IT department is funded based on those priorities with the discretion it needs to manage it from within. I’ve been at an organization that made that transition, and it was a definite improvement in the working environment, in my opinion.

Now the really interesting thing is getting that initial definition of the enterprise. The more I think about this, the more I realize that this definition is the job of Enterprise Architecture. We must architect the enterprise, meaning we come up with the proposal for what things should be enterprise and what things are best left to sub-domains. But wait, this sounds like a task, not a team. Initially, it is a task. Ongoing, however, the refinement of that definition and adjustment based on changes in the business and its climate will occur, and that is the job of the team. On top of that, there’s the enforcement aspect of making sure everyone continues to play by the rules. As an example, think about architecting the enterprise of the United States of America. The initial “architecture” creating the federated governing structure, with some capabilities provided at a federal, or enterprise, level (e.g. military forces) and others left to the discretion of the states. Since that time, the government has continued, in part, to tweak and refine what things are handled federally and what things are handled locally. The approach must always be monitored for effectiveness, responsiveness, cost, etc. Imagine, now, a different world where that structure doesn’t exist, and every cross-cutting topic is brought before a collection of state governors. Debate would occur on every single item, decisions would be extremely slow, and people with the power ($) to do so, simply would, even when it may not be in the best interest of the country as a whole. Take another scenario in recent press like immigration and border security. If the federal government says, “we must secure our borders” but doesn’t create a centralized approach for doing it, what happens? States with money may do a good job, states with others will not. One state’s approach may be completely different, making it difficult for legal immigrants to travel from state to state because the rules are so different. In other words, while all agreed that it was an enterprise goal, it was not managed as an enterprise capability. This is what happens in IT departments around the globe every single day.

My advice to my fellow EA practitioners: if you’re struggling, focus on defining the enterprise first getting buy off from senior executives on what items must be managed at an enterprise level, and then guide the transition to that approach.

A challenge for virtually any position with “Enterprise” in the title, but especially so with Enterprise Architecture, is to continually show that they are adding value to the organization. Why? Because typically enterprise architects are not directly associated with delivery. In most IT organizations, things get delivered through projects, and enterprise architects don’t typically play the role of project architect. At best, there is an indirect association with delivery.

First off, the organization must understand that there is a need in the organization for non-project activities. It’s funny how there’s plenty of positions outside of IT that have indirect relationships to business delivery, so it’s still a bit surprising that there is still resistance toward Enterprise Architecture in many organizations. This post isn’t about how to convince management of the need for Enterprise Architecture, though. It’s about the two paths that you can go once you have that management support.

The first path is all about enforcement. Someone in senior management is upset about the decisions that are being made on projects, and as a result, they put a police force in place to review project activities. That police force is Enterprise Architecture. A personal pet peeve of mine is when the police force is put in place, but the laws are not. When that happens, project teams are at the mercy of the individual that is reviewing the project and whatever their personal interests are. Those personal interests may have nothing to do with what senior management wants, or what the project team is tasked to do. If you’re going to put a police force in place, you first need to have laws. Anyway, the point of this is that a police force approach can result in a lot of animosity. On the plus side, Enterprise Architecture does get visibility into all projects with the power to influence their direction. Also, sometime it is necessary to put a police force with a very big stick in place to force some change on an organization, but it does so at the expense of corporate culture and can result in a lot of ill will.

How do you avoid this? By remembering that as an enterprise architect, your role is not to audit, but to assist. Everything you do should be done with the thinking that your are helping to deliver, helping people to make good decisions, and helping to make their job easier, not more difficult. If you take this approach, you may still have to review projects, but your focus should be much more on communication, education, and evangelism. If you are setting standards, you should be communicating the standards, the justification for them, and the expected results to see when they are followed. If those results aren’t achieved, you should be working with the teams to understand why and get them back on the right path. Another pet peeve of mine is when someone says, “No, you can’t do that” but fails to follow up with instructions on what the right way is.

In short, if you are in a role that is normally not assigned to project teams, you must remember that you are still part of the delivery team, and everything you do should contribute to the successful delivery of a solution that meets the goals of the project and the goals of the business. It’s about being helpful, not a hinderance.

This article had an interesting interview with Tim Walters, an Information and Knowledge Management analyst with Forrester. In it, he emphasizes the role of Social Computing. He’s certainly not the first one to do this, but his comments caused me to think a little harder about this. I like Social Computing, and I have certainly been an active participant in the technology area via this blog and Twitter. I have also leveraged my web site, Facebook, and other resources for more personal community sharing. At the same time, i consider myself the exception rather than the norm. So, when analysts are talking about the need for companies to leverage social computing technologies more prominently, I wonder whether this is playing to a very small market segment.

If you are an information management company/content provider, how many of your customers want to participate in a community around your information/content, and how many just want to continue to be consumers? I think the tools have enabled people who wanted to participate all along to be able to do so, but have the tools converted people who otherwise would not have participated? I don’t know. What I have tended to see are a few people (like me) who love to be an active participant, a few people who love to comment/critique, but never offer original content of their own, and then the other 80% of the people who passively consume, if even at all. If we start forcing content into a more conversational, interactive setting, especially when that content needs to used for business purposes, are we going to make it more difficult to use for the 80% mass market?

The end result is that online communities and social computing technology, like anything else, must make business sense. They can’t be approached blindly. It can be a very powerful tool, but it can also be a very distracting one if it takes away from your core focus.

What looks to be a very simple question is actually a very tough one. The answer to this is of particular importance to a domain architecture team (a team whose scope is larger than a single project or solution), but the principles apply even to a solution architect. The solution architect has a slight advantage that they’re typically working with a team that has a single common goal: deliver the solution. Domain architects, however, must balance the delivery focus of project teams with setting the stage for systemic success across a broader portfolio of solutions, be it within a line of business or across the entire enterprise.

To me, architecture is about creating a categorization that establishes boundaries. These boundaries partition the solution into different areas. What’s the most frequent reason for partitioning? To create areas of responsibility. Within a project, your break things down to a sufficient level in order to be able to hand off units of work to individual developers or engineers, who now have responsibility for delivering that work. The biggest challenge is where those units of work overlap. When thinking of the typical Visio diagrams associated with architecture, this type of view is consistent with a boxes and lines view. We’re interested in what the boxes are and what’s on the lines (the interfaces and messages) that connect them.

While this boxes, lines, and responsibility approach works for both project and domain architects, there is one big, significant difference: the timeframe of responsibility. Once a project has been delivered, the development responsibilities typically go away. Your decisions on how partition the project are solely based on getting it delivered. A domain architect, however, is interested the full lifecycle of responsibility for a component. It’s not just the initial development, but it’s the ongoing care and feeding, the onboarding of new consumers, etc. If we don’t partition things to support future change, the pain involved in supporting that change will be high. The desire to partition things to allow for an efficiently managed portfolio may not be the same partitioning that allows for the most efficient development. These needs have to be balanced. In the perfect world, the partitioning for portfolio management could occur outside the context of any project, allowing the “optimal” partitioning to be used as an input by the project architect to balance these needs. In reality, that context doesn’t exist, and we’re doing our best to build it as we go along.

This type of approach can be challenging for domain architects when many people have the perception that the architect is the nuts and bolts person, looking at how things are built, rather than what gets built. That’s because many architects have gotten there by being a senior developer or engineer. I’m not suggesting that the “how” portion isn’t important, especially because the “how” decisions also have a lot to do with partitioning, but the “what” is increasingly important, because that ultimately defines what must be managed for the long term. If those units are difficult to change over time because of poor partitioning from a responsibility and ownership viewpoint, it will be a struggle.

What are your thoughts on what things are architecturally significant?

With the announcement of docs.com on Wednesday from Microsoft, it got me thinking about what I’ll call the consumer cloud. As my iPhone has become a critical device for me, and I expect my iPad 3G to do the same when it arrives on 4/30, I find myself longing for better use of the cloud for my information. The simplest example is the iTunes tether. I listen to quite a few podcasts, and I have a script set up every night on my MacBook Pro to download the latest podcasts and then sync my iPhone, so they’re ready for my drive in to work in the morning. It’s a big problem when I travel, though, because the iPhone only knows about the podcasts that have episodes, and for feeds that don’t exist in iTunes, like my personal playlist for IT Conversations, I have no way of downloading new episodes without the tether to my MacBook. With my iPad on the way, I expect that the need for a cloud repository will grow even more. Some tools provide their own cloud-based storage, like Evernote. There are cloud repositories or syncing utilities like DropBox, MobileMe, and Box.Net, but so far, the integration with the content editing or viewing tools isn’t there, in my opinion. That’s especially surprising with MobileMe, at least for the iPhone.

These needs are what makes Microsoft’s announcement so interesting. Ironically, even Apple showed a hint of recognizing the power of Facebook in the recent “dog” iPhone ad. When they discussed sharing pictures in the commercial, they weren’t shared via MobileMe, they were shared via Facebook. If Facebook becomes the de facto place for sharing, does that make it the de facto cloud storage solution for the consumer segment? It arguably is already doing that for photos. My brief visit to docs.com emphasized Facebook’s role in access control more so than actually storing the documents, but at that point, Facebook is still the gatekeeper. With the enormous community that Facebook has, it will be interesting to see what happens to things like MobileMe. What is clear is that Facebook is in the driver’s seat, and everyone else is either chasing them or hopping aboard the Facebook bus.

A recent conversation with a colleague delved into the complicated world of new technology decisions. At every organization I’ve been at, this has been a source of contention between four major groups: Enterprise Architects, Domain Architects, Development Teams, and Engineering Teams. I specifically listed Enterprise and Domain Architects separately, because I’ve seen contention between those two groups. It’s easy to come up with scenarios where each one of these teams should be involved, but it’s most problematic when one team tries to “own” the process.

Why does this struggle for ownership occur? Let’s start with a development team. First and foremost, they spend nearly all of their time on projects, which is where things get delivered. They are typically the ones closest to the immediate business need as represented by the project requirements, so they have fewer challenges getting justification or funding. They claim they need the new technology to deliver to the business, so they have a vested stake and want control over the decision.

An engineering team is also involved with projects, but has a challenge of remaining relevant when the project ends. The technology typically gets handed off to an operations team, and if the engineering team has built shared infrastructure, rather than one off infrastructure, there may not be much to do until the vendor releases the next version. Given that, it’s likely that the engineering team will expand into the world of technology architecture, but potentially only with the vendors they know, rather than a vendor-neutral architectural approach. This creates a risk of driving technology adoption based on new features rather than on company need, can create conflict with the technology architecture team, if one exists, and with other technology areas when the continued feature creep results in overlap with other domains. Unfortunately, engineering teams don’t have as much visibility into the business need, because that’s all funneled through projects and the development teams, so it sets the stage for tension between the development and engineering areas.

Now let’s throw in architecture. First, there can be conflicts within architecture teams, if there’s a separation and different reporting relationships for enterprise architects and portfolio/domain architects. Second, enterprise and domain architects can frequently be disconnected from both the “need” process of the projects and the technology delivery of the engineering team. Clearly, the right place for these roles to play is at the portfolio management level, where categorization, prioritization, and strategy takes place that results in the needs of individual projects. That doesn’t always happen though, and these roles often wind up having to get involved by mandate, becoming the gatekeeper or bottleneck that everyone tries to avoid.

As many have said, there are typically far more ways to mess something up than there are to do it correctly, and this is certainly one of them. Coming back to the idea of trusted advisor, my theory is that any approach that tries to mandate that technology introduction only come through one path is probably not going to work. Lots of people get great ideas, and guess what, not all of them come out of any particular role, and plenty of them come from outside of IT. (By the way, the same should hold true in reverse, IT can come up with plenty of good business ideas, just as the business can come up with good IT ideas.) The role of the architect is to be the trusted advisor and provide the appropriate context to make things successful. If someone has a great idea about a new technology, don’t stifle them because you didn’t come up with it, advise them on how to make it work based upon the context you have as an enterprise or domain architect, or advise them that it’s not going to be successful based upon that same context. That’s what an advisor does, and providing the appropriate guidance, whether it is what the other person wants to hear or not, is what will create trust. There will always be people that may be out of alignment with the business needs and priorities, if you don’t create alignment (either by adjusting the individuals view or adjusting your needs and priorities), you will be destined for frustration, splintering, and potential lack of success. Create alignment, and create an environment where appropriate ideas can thrive regardless of the source. That’s the role of the trusted advisor, and that’s a big part of what enterprise and domain architects should do.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.