Todd Biske: Outside the Box

August 26th, 2010 by Todd Biske

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.

August 12th, 2010 by Todd Biske

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.

August 11th, 2010 by Todd Biske

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.

July 20th, 2010 by Todd Biske

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.

July 15th, 2010 by Todd Biske

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.

June 14th, 2010 by Todd Biske

I read this report from GigaOM and it got me thinking about the challenges of trying to create a successful Facebook-like environment in the enterprise.

Challenge #1: Smaller community. Facebook has over 400 million active users. Your company will have thousands. You can assume that only a portion of those will be active contributors, and that within that smaller group, those people will be split into smaller communities of interest. This leads to a trickle of information flow, which isn’t going to keep people coming back. Even within Facebook, I wonder how many users are just playing games, versus having interactions with friends. The Facebook statistics page does not provide this information. This is important because…

Challenge #2: Enterprise apps do not exist as part of the social platform, and there will be a long migration for existing companies before that changes. If anything, the trend today is to put social networking features into the app, rather than building the app within a social networking platform. That’s not a surprise, as what platform would you choose?

Challenge #3: The browser dominates the deployment model. I try not to generalize my personal preferences, but if I am going to interact with something on a regular basis, it needs real estate on my desktop. That’s why I use Seesmic Desktop for Twitter/Facebook messaging. It’s always open. A browser takes up too much real estate, so eventually that page is out of sight, and out of mind. I think a push model is the only way to go to be successful.

Challenge #4: The enterprise does not have a culture of sharing. I don’t know the root cause of this, but in general, I have found that most enterprises only share information when it is required to get a task done. Rather than seeking out interested parties, information owners sit back and wait for information seekers to come to them. This results in a lot of wasted time and effort in finding out those information owners. In general, I think there are way too many barriers that prevent information sharing, whether due to corporate culture, legal and regulatory environments, internal politics, or many other reasons.

So what do we do? You’ll have to read my next post where I will try to ofer some suggestions for addressing each of these.

May 5th, 2010 by Todd Biske

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.

May 3rd, 2010 by Todd Biske

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.

April 23rd, 2010 by Todd Biske

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?

March 25th, 2010 by Todd Biske

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.

February 5th, 2010 by Todd Biske

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.

I just posted a response to a question about the iPad in an enterprise setting over in an eBizQ forum and decided that I wanted to expand on it here in a blog post.

Much of the discussion about the iPad is still focusing on a feature by feature comparison to a netbook or a laptop. The discussion can not get out of the 20 year old world of keyboards, mice, and the windows and desktop metaphors. To properly think about what the iPad can do, you need to drop all of this context and think about things in new ways. In my previous post on the iPad, I emphasized this point, stating that the iPad is really about taking a new form of interaction (touch, with completely customizable interface) and putting it on a new form factor. In answering the eBizQ question, I realized that it goes beyond that. The key second factor is context awareness.

Back in 2007, I attended the Gartner Application Architecture, Development, and Integration Summit and the concept of “Context-Oriented Architecture” was introduced. In my blog post from the summit, I stated that:

[Gartner] estimates that sometime in the 2010′s, we will enter the “Era of Context” where important factors are presence, mobility, web 2.0 concepts, and social computing.

In that same post, I went on to state that this notion of context awareness will create a need for very lightweight, specific-purpose user interfaces. While at the time, I was leaning toward the use of Dashboard widgets or Vista sidebar items, but guess what has taken over that category? iPhone and iPod Touch apps. Now, we have the potential for a device with a larger form factor that can present a touch-based interface, completely tailored to the task at hand. This is another reason why I don’t see multi-tasking as a big deal. The target for this audience isn’t multi-tasking, it’s for these efficient, single-purpose interfaces. Imagine going into a conference room where your iPad is able to determine your meeting room through sensors in the building, where it knows what meeting you’re in and who else is in the room through calendar integration, it knows the subject of the meeting, and can now present you with a purpose-driven interface for that particular meeting. Our use of information can be made much more efficient. How many times have you been in a meeting only to wind up wasting time navigating around through your files, email, the company portal, etc. trying to find the right information. What if you had an app that organized it all and through context awareness, presented what you needed? The same certainly holds true for other activities in the enterprise beyond meetings. As we have more use of BPM and Workflow technologies, it is certainly possible that context awareness through location, time, presence of others, and more can allow more appropriate and efficient interfaces for task display and execution, in addition to providing context back into the system to aid in continuous improvement.

This isn’t going to happen overnight, but I am very excited to see whether Gartner’s prediction of the 2010′s being the “era of context” comes true. I think it will, and it will be great to look back from 2020 and see just how much things have changed.

February 1st, 2010 by Todd Biske

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.

A succession of tweets between Forrester’s Gene Leganza and Clay Richardson along with Brenda Michelson of Elemental Links caught my attention this morning. At Forrester’s Enterprise Architecture Forum next week, Clay will be reviewing a few case studies for Social BPM. It’s too bad that I won’t be there, because this sounds very interesting.

I haven’t seen any definitions yet of what socially-enabled BPM is, so I thought I’d throw together my own thoughts. First off, let’s take two dominant social technology platforms, Facebook and Twitter. I’ve previously posted that an internal Facebook for the enterprise could be revolutionary for inter-company communication. I’ve also previously posted on the role of Twitter as an information bus. So, now combine the human-facing communication of either platform’s news/event stream, the application platform of Facebook, and toss in some process modeling, orchestration, and universal task management capabilities on top of it, and I do think you have socially-enabled BPM. What could be most compelling is if there’s a way to combine the communication features of the social technology platform for “ad hoc” processes with the more formally modeled and managed processes that are the strong suite of BPM platforms to get a better view (and hopefully better management) of the processes in the enterprise as a whole.

I look forward to hearing what others think about the case studies Clay will be presenting. This is definitely an emerging area where there are opportunities to lead the back and be revolutionary.

Update: Here’s two posts from Clay on the subject that he forwarded to me. It looks like my thinking is consistent with what he had previously written on the subject. The first is titled “Social Technologies Will Drive The Next Wave Of BPM Suites” and the second is titled “BPM Promises ‘Simplicity’ In 2010. Is This ‘Hope We Can Believe In’ Or Still A Pipe Dream?”.

January 29th, 2010 by Todd Biske

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.

I participated on a panel discussion on communication and enterprise architecture, hosted by Bob Rhubart of Oracle. Part one is now posted on Oracle’s Technology Network, with parts 2 and 3 to follow soon.

January 26th, 2010 by Todd Biske

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.

David Linthicum continued the conversation around design-time governance in cloud computing over at his InfoWorld blog. In it, he quoted my previous post, even though he chose to continue to use the design-time moniker. At least he quoted the paragraph where I state that I don’t like that term. He went on to state that I was “arguing for the notion of policy design,” which was certainly part of what I had to say, but definitely not the whole message. Finally, Dave made this statement:

The core issue that I have is with the real value of the technology, which just does not seem to be there. The fact is, you don’t need design-time service governance technology to define and define service policies.

Let’s first discuss the policy design comment. Dave is correct that I’m an advocate for policy-based service interactions. A service contract should be a collection of policies, most if not all of which will be focused on run-time interactions and can be enforced by run-time infrastructure. Taking a step backward, though, policy design is really a misnomer. I don’t think anyone really “designs” policies, they define them. Furthermore, the bulk of the definition that is required is probably just tweaking of the parameters in a template.

Now, moving to Dave’s second comment, he made it very clear that he was talking about governance technology, not the actual governance processes. Speaking from a technology perspective, I’ll agree that for policy management, which includes policy definition, all of the work is done through the management console of the run-time enforcement infrastructure. There are challenges with separation of concerns, since many tools are designed with a single administration team in mind (e.g. can your security people adjust security policies across services while your operations staff adjust resources consumption while your development team handles versioning, all without having the ability to step on each other’s toes or do things they’re not allowed to do?). Despite this, however, the tooling is very adequate for the vast majority (certainly better than 80-90% in my opinion) of enterprise use cases.

The final comment from me on this subject, however, gets back to my original post. Your SOA governance effort involves more than policy management and run-time interactions. Outside of run-time, the governance efforts has the closest ties to portfolio management efforts. How are you making your decisions on what to build and what to buy, whether provided as SaaS or in house? Certainly there is still a play for technology that support these efforts. The challenge, however, is that processes that support portfolio management activities vary widely from organization, so beyond a repository with a 80% complete schema for the service domain, there’s a lot of risk in trying to create tools to support it and be successful. How many companies actually practice systemic portfolio management versus “fire-drill” portfolio management, where a “portfolio” is produced on a once-a-year (or some other interval) basis in response to some event, and then ignored for the rest of the time, only to be rebuilt when the next drill occurs. Until these processes are more systemic, governance tools are going to continue to be add-ons to other more mature suites. SOA technologies tried to tie things to the run-time world. EA tools, on the other hand, are certainly moving beyond EA, and into the world of “ERP for IT” for lack of a better term. These tools won’t take over all corporate IT departments in the next 5 years, but I do think we’ll see increased utilization as IT continues its trend toward being a strategic advisor and manager of IT assets, and away from being the “sole provider.”

January 13th, 2010 by Todd Biske

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.

David Linthicum started a debate when he posted a blog with the attention grabbing headline of “Cloud computing will kill these 3 technologies.” One of the technologies listed was “design-time service governance.” This led to a response from K. Scott Morrison, CTO and Chief Architect at Layer 7, as well as a forum debate over at eBizQ. I added my own comments both to Scott’s post, as well the eBizQ forum, and thought I’d post my thoughts here.

First, there’s no doubt that the run-time governance space is important to cloud computing. Clearly, a service provider needs to have some form of gateway (logical or physical) that requests are channeled through to provide centralized capabilities like security, billing, metering, traffic shaping, etc. I’d also advocate that it makes sense for a service consumer to have an outgoing gateway, as well. If you are leveraging multiple external service providers, centralizing functions such as digital signatures, identity management, transformations, etc. makes a lot of sense. On top of that, there is no standard way of metering and billing usage yet, so having your own gateway where you can record your own view of service utilization and make sure that it’s line with the what the provider is seeing is a good thing.

The real problem with Dave’s statement is the notion that design-time governance is only concerned with service design and development. That’s simply not true. In my book, I deliberately avoided this term, and instead opted for three timeframes of governance: pre-project, project, and run-time. There’s a lot more that goes on before run-time than design, and these activities still need to be governed. It is true that if you’re leveraging an external provider, you don’t have any need to govern the development practices. You do, however, still need to govern:

• The processes that led to the decision of what provider to use.
• The processes that define the service contract between you and the provider, both the functional interface and the non-functional aspects.
• The processes executed when you add additional consumers at your organization of externally provided services.

For example, how is the company deciding what service provider to use? How is the company making sure decisions by multiple groups for similar capabilities are in line with company principles? How is the company making sure that interoperability and security needs are properly addressed, rather than being left at the whim of what the provider dictates? What happens when a second consumer starts using the service, yet the bills were being sent to the first consumer? Does the providers service model align with the company’s desired service model? Does the provider’s functional interface create undue transformation and integration work for the company? These are all governance issues that do not go away when you switch to IaaS, SaaS, or PaaS. You will need to ensure that your teams are aware of the contracts in place, and don’t start sending service requests without being properly onboarded into the contractual relationship. Your internal allocation of charges takes multiple consumers into account, if necessary. All of these must happen before the first requests are sent in production, so the notion that run-time governance is the only governance concern in a cloud computing scenario is simply not true.

A final point I’m adding on after some conversation with Lori MacVittie of F5 on Twitter. Let’s not forget that someone still needs to build and provide these services. If you’re a service provider, clearly, you still have technical, design-time governance needs in addition to everything else discussed earlier.