Todd Biske: Outside the Box

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.

Barnes and Noble has introduced a $149 Wi-Fi version of its Nook eReader. This has now reached a price point where I think parents may consider purchasing one for their children. Having recently moved, I know where my budget for book purchases has gone recently: kids books. This ranges from learning to read books all the way up to the several-hundred-page series books like Harry Potter and Percy Jackson. While there’s no easy way to get all of these existing books onto an eReader (I think demand would shoot into the stratosphere if there was), there’s certainly no shortage of new book purchases in the future, either. So what would make a great kids eReader?

First, I think existing eReaders like the Nook or Kindle are probably fine for the Harry Potter/Percy Jackson age group, say 9 and up. They should have no problem using the device, it’s more a question of taking care of the device. For the under 6 age group, I don’t think current eInk screens are going to provide the right amount of visual stimulation, so at best, it’s probably a device best used while your child is in your lap and you’re reading to them. They’ll pick up the interface of the device, and be ready to go when they reach the chapter book stage of reading. The 7-8 age group is the trickier one. It’s going to get thrown into a school backpack, have who knows what smeared all of it from their hands, etc., so you get the point. The device needs to be of equivalent durability to a Nintendo DS. Most 7-8 year olds I know have one of these.

In terms of features, I think Barnes and Noble has it right with the WiFi only. The kids aren’t going to be purchasing books in airports- it’s a reading device. I’d even be okay with a device that only allows USB sync, but since I wouldn’t expect the removal of WiFi to change the price point, I’d rather have it than not. If you can give me a $100 price point with sync only capabilities, like an iPod Nano or Shuffle, even better. Purchasing from the device would need to be disabled at the discretion of the parent, especially with the one-click purchase approach of the Kindle. As a parent, I would prefer to go to a website, make the purchase, and then choose to deliver to my kids’ devices when they connect. Add in date-based delivery options, and friends and family could purchase presents that automatically show up on the kids’ birthdays, or we could even have link in to the North Pole and allow Santa to deliver them to the device on Christmas morning. eInk-based screens are a must, because the kids will forget to charge the device, so battery life is critical. Finally, we must be able to share books across multiple devices. I don’t want to have to buy separate copies of the latest book by Rick Riordan for each device, as my kids share the books now.

The real question is whether a dedicated device makes sense for your children. I think we’re looking at an age group of 7-11. From 12 and up, there’s a good chance your child will have an iPad/Netbook/Tablet/Laptop of their own with a screen space suitable for reading. Does the independent eReader get put on the shelf at that point? I know I have stopped using my Kindle now that I have the Kindle app on my iPad. Personally, I think the answer to the question is still yes, even if only used for 5 years from ages 7 to 11. 5 years for any electronic device is a pretty good life span. We spend $150 on a NintendoDS for probably 5 years of use, why wouldn’t we do the same for an eReader with more educational value? As long as there’s a software version of the reader for the multi-purpose device, all their books can go with them.

The final piece of the puzzle would be to have Scholastic tie their school book programs into this. Parents should be able to purchase for any eReader from their website and have it tie into the classroom or school fund raising programs that they offer. While the vertically-integrated device and store models of Amazon and Barnes and Noble probably won’t allow purchases for other devices, a publisher-owned store should.

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.

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.

While my iPad will arrive in “late April,” I’ve been following all the buzz this week, reading reviews, checking out the app store, etc. Late April can’t get here soon enough in my opinion. Here’s what has me so excited about it.

I’ve always preferred taking notes electronically, but in the past three or fours, there’s a stigma associated with that. Starting with blackberries and getting worse when laptops started becoming standard corporate issue, people stopping paying attention in meetings. I’ve been to many meetings that had no laptop and no mobile phone rules. Even if you were taking notes, the screen is a bit distracting to others. The small footprint of the iPad should be less distracting, and the fact that it doesn’t do multi-tasking means that if I have Evernote open, that’s the only thing that will be there.

As best I can tell, this device is laser-focused on content consumption. Not just books, audio, or video, but all content. The form factor is better than iPhone/iPod Touch, and it strips away all of the unnecessary stuff to make that experience as good as possible. I spend a lot of my day simply consuming information, and if this improves that experience, that’s a positive. Where it has the opportunity to excel is in context-specific content consumption. I’m not talking about surfing the web here, that’s general purpose. I’m talking about things like the MLB At Bat application. I have it on my iPhone, but when I saw the screen shots of the iPad with, I thought, “Boy, I could see myself taking this with me to Busch stadium as I watch the game live.” I doubt I will, but I’m tempted

Here’s another example which I think could be really cool. How many of us check menus of restaurants online? Imagine going into a restaurant with your iPad, and having the menu for the restaurant automatically appear, complete with ordering capabilities? While today, you’d have to have the app for your favorite restaurant pre-loaded, this is the kind of thing that could be possible and makes much more sense for a device like an iPad or iPhone than it would for a laptop.

I never thought about using the iPad as the multi-purpose board game for the family until seeing some of the apps. I can see me doing this with my kids. The form factor just works for this, while passing around a laptop with an unnecessary keyboard doesn’t.

As my kids get older, I think this will be the perfect first device for them. Time will tell whether the desktop/laptop is better suited for term paper and presentation creation, which is why I think it was smart of Apple to create iWork for this.

I think this will continue to nudge things toward cloud storage. This is probably the one area where I think things should be opened up, but the problem is there is no standard. Apple will likely drive Apps to use MobileMe for cloud storage and synchronization, and third party apps can already do the same. I can also see where someone would prefer DropBox, or some other solution, though. Until there’s a standard and well adopted way of talking to cloud-based storage providers, I wouldn’t expect Apple to do anything other than their own system.

As one of the early reviewers noted, the things I am most excited about are the apps that have yet to be developed. As I’ve said before, people who are looking at this as a laptop replacement are missing the point. This is a new form and new platform, primarily (but thankfully not exclusively) focused on content development. It is intentionally not as broadly focused as a laptop or desktop. If you need something with broader capabilities, go get a laptop or desktop. You don’t see Apple phasing out the MacBook or iMac lines anytime soon, do you?

As for the negative comments out there, here are my thoughts. On the lack of multitasking support, I think this will fade away. I’d rather see Apple take the conservative approach they are to preserve the experience and keep this positioned as something other than a laptop. Developers can assume they have my full attention, and don’t need to worry about multiple windows, resizing, etc. All of that takes away from the user experience which is what Apple has always been so good at. There is room for improvement, where a stack metaphor (so you only see the app on top) could be useful, such as when I click on a URL in a mail message. I want to close the browser and go back to mail. Today, that process is inefficient.

On the closed Apple platform, as a consumer, I don’t buy into the social/political movement around having an open platform. I just want it to work well and the tasks I need it for. Let the consumers decide. For the mass market application developers, I believe they will go where they can make money, period. I don’t think they get hung up on having to have one interface in Objective C and another one in Flash, as long as they’re making money. Could they increase profit margins if it were all in one platform and one framework, sure. Apple has to preserve their experience, because that’s their differentiator. They’re not about to sacrifice it, and why should they? Are they over-conservative, well, probably, but I’d rather have that then a free-for-all.

On Flash, again, from a consumer perspective, it’s really not a big deal for me. It hasn’t been an issue for me on my iPhone, and I don’t expect it to be a big deal for me with the iPad. The only concern I see, since I mentioned that I see this as a great first device for my kids, is that the games my kids play aren’t available. They can’t run Club Penguin, ToonTown, or Webkinz on an iPad. It would not surprise me at all, however, to see a Club Penguin or ToonTown app show up very soon. I don’t believe the thing holding these back was the lack of Flash on the iPhone, I think the thing holding them back was that it made absolutely no sense to put those applications on a screen the size of the iPhone. The iPad changes that. Flash support is really a business decision, because as soon as the iPad supports it, guess what? The whole app store ecosystem could be tossed on its head. That doesn’t make business sense for Apple. Google’s differentiator is not the experience. I don’t think they care where you get your apps from or how you pay for them, as long as they improve their advertising business. If the experience is not as important to you, but being able to put whatever you want on it is, then the iPad may not be for you. I think there will always be a sustainable market for more closed, easier to manage devices, and that’s where Apple rules the roost. That market will never achieve 80% share, but that’s okay. It’s certainly enough to keep a company very successful as Apple has shown over the past few years.

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 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.

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.

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?”.