Todd Biske: Outside the Box

By now, everyone who’s interested has probably watched Apple’s 25 minute video on the features of the iPhone. I did, and it was the clincher to convince me to find a line at an AT&T store somewhere near my house on Friday (I suspect the lines at the Apple Store at West County Mall in St. Louis will be far too long for my taste).

I previously had posted some thoughts on Apple’s announcement that applications for the iPhone can be written using Web 2.0 technologies (except Flash, for now). Patty Seybold contributed to the conversation with some comments and on her blog. After watching the video, I wanted to continue the conversation.

Besides games, which really are using the device for an entirely new purpose, the only area where I see a need for third party applications is in the “Internet Communicator” domain. Clearly, no one needs to write anything to help it play music, watch videos, or make telephone calls, Apple’s taken care of that. For me, Internet communication comes down to four things: a web browser, an email client, an RSS reader, and Instant Messaging. Apple’s taken care of two of them, or possibly three, presuming Safari on the iPhone has the same RSS capabilities as the desktop version. They don’t have Instant Messaging, which is a glaring flaw as far as I’m concerned. While your average teenager may be more concerned about SMS, I tend to rely on IM systems. Many enterprises don’t allow outside IM communication from corporate machines, so that means using a phone for it. I can’t find any good reason why Apple’s wouldn’t have included it. If they felt the primary use was phone-to-phone communication, then why did they not include MMS and instead make you email pictures? Anyway, I digress.

Let’s look at the RSS space. Clearly, there are web-based RSS readers. Safari itself is one. Google Reader is extremely popular. I prefer a standalone reader and use NetNewsWire, but even it syncs with NewsGator to allow for web based access if I so desire. So, Apple’s strategy seems to make sense at this point. The biggest challenge, however, is going to be the diminutive screen. There’s a whole crop of web applications beginning to appear (you can keep up with them via the iPhone Application List) which are effectively web sites that are designed to fit within the iPhone screen. While this can all be managed through bookmarks, I’d much rather have them have an icon on the home page of the device. After all, it’s the strategy Apple itself has chosen.

The YouTube, Google Maps, and Weather applications are clearly examples of web-based applications that were tailored for the diminutive screen, simply because the existing web-based interface was probably designed with at least a 640×400 screen in mind, if not more. This is an implicit recognition that zooming and dragging within full size web sites simply won’t cut it from a usability standpoint. It would be interesting to find out just how much of those applications are web-based, and how much of the presentation is actually generated on the phone, versus on some server.

I would fully expect Apple to issue an update to the iPhone to allow it to have a Home Screen Manager, just like the Dashboard Manager in OS X. While the Dashboard provides APIs for saving preferences locally, I don’t even think this is an absolute requirement for the iPhone, which should eliminate any security concerns. The only thing stored is a bookmark. As long as all of these applications rely on centralized cookie management, there’s no reason why all preferences can’t be stored on the server side. The real question is whether developers will produce the iPhone specific interfaces. I think they will, and I think it’s great that Apple isn’t requiring them to use anything proprietary in doing so. As other smartphones add full web browsers to their mix, these sites that were designed for iPhone will probably be usable, albeit not perfect given subtle differences in screen size, without modification.

Sorry, I need to rant, although, not as much as I originally thought. I just read the interview with Gartner’s Paolo Malinverno on SOA Governance at SearchWebServices.com. I read his answer to the question “How do you define SOA governance” and decided I needed to blog on this, although he made up for it a bit in his answer discussing “phases.”

Anyway, in his definition of SOA governance, he split it into two halves. The first half is about making sure that important decisions go through to appropriate people and that these people have appropriate input to make those decisions. The second half is making sure those decisions are followed. I wanted to scream out, “Where are the policies???” But, he did mention in his answer to the next question that there is a “phase which defines what the policy is.”

Unfortunately, I really didn’t feel like this article made the whole picture crystal clear, so let me do that here.

1. People.
2. Policies.
3. Process.

Step one is to figure out who your governors are. Before you can have governance, you need to have someone responsible for creating the policies to be governed. Paolo made the statement, “This set of decisions, I wanted them covered.” I think it’s more vague than that. I doubt any organization already knows all of the decisions that need to be made. It’s more likely that they know the desired outcome, and now need someone to work backwards to figure out what policies will enable that behave. For example, there’s the holy grail of IT, reuse. If the desired outcome is reuse of services, you need someone to work backward and figure out where policies are needed to make that outcome a reality.

Step two, therefore is about establishing the policies. The key to this is making sure the policies exist is some form other than the memories of the governors. Put them on paper in the form of patterns or reference architectures. Codify them and rely on tools to automate it. If the only place the policies exist are in the brains of your governors, all you’ve created is a bottleneck. This results in a situation like this:

On the one side up in the ivory tower sits the governors, pontificating away. On the other side are their constituents (the developers) busily working away in the trenches. Only on a rare occurrence are the constituents able to gain audience with the governors in an exercise known as a review. At such review, the constituents demonstrate their mind-reading abilities in predicting what things the governors care about, and praying that they don’t reach the dreading situation of disagreeing governors who hadn’t even talked to each other about their own opinions.

Clearly, we need some documented policies here.

Well, that helped a bit, as the mind reading isn’t necessary anymore, but as is most often the case, the constituents either disagree with the policy, or don’t bother to look at it until it’s time for their review, only then to find out that they are out of compliance. Now it’s time for the filibuster! At this point, the best course of action from the constituent’s standpoint is to simply put it off until the cost of making it compliant is far more expensive than the perceived cost of leaving it non-compliant. It usually entails telling the business sponsor that the project can be released in two weeks or it can made compliant and released in 3-6 months. Thus ensues the debate between the business leaders and the elected officials, yada, yada, yada. And this doesn’t even touch on the subject of policies which the constituents don’t like, and claims that the governors are being overly influenced by lobbyists and out of touch with the people.

To conquer this one, and get the right process in place, I recommend the following model:

In this model, we introduce a third party that bridges the gap and is the key to successful policy enforcement. Keeping policies up to date can easily be a full time job, as is building solutions. What we need is a third role that does a bit of both. I’ll call it the solution architect. These individuals are able to participate in the policy setting process, but they also are the key enforcer on projects. They may have the role of technical lead, but at a minimum, they have the authority to set direction on a project. In this way, they help projects apply policy at the right time, and they help the governors define relevant policy. Formal reviews may still take place, but hopefully, they’re much faster and focused on increasing communication and collaboration instead of being a potentially belittling exercise and demonstration of authority, which isn’t good for the health of the organization.

Most importantly, people must know their role. The governors should be judged on their ability to produce relevant policy in a timely manner. Constituents should be judged on their ability to produce solutions in a timely manner. Solution architects should be judged on a combination of the two.

I previously posted some thoughts on the new book from the Neils at MacehiterWard-Dutton along with Jon Collins and Dale Vile from Freeform Dynamics called “The Technology Garden: Cultivating Sustainable IT-Business Alignment.” I finally got a chance to pick it up again, and I thoroughly recommend chapter 8, “Foster relationship with key IT suppliers” for anyone who has an involvement in vendor decisions. Working with vendors is an art, and it’s not just the department head who needs to do it. They give some practical guidance on how to determine who your strategic vendors are, and who the vendors are that you simply deal with on a transaction by transaction basis. In addition to this, they also give prescriptive guidance on working with them, and the art of the win-win solution.

In addition to being of value to vendor relations, anyone adopting SOA should also understand this chapter. Why? Because if you’re a service provider, a lot of the same conflicting pressures occur between consumer and a provider. Strive for the win-win situation, and you’ll be better off. It’s not easy to do, especially when you have multiple consumers each with their own priorities.

Simon Brown, on his blog “Coding the Architecture,” had a good, short post on tactical solutions. One of the points he made that I liked was this:

For me, a tactical solution can be thought of as a stopgap. It’s an interim solution. It’s something potentially quick and dirty. It satisfies a very immediate need. Importantly, it has a limited lifespan.

It’s the last sentence that hits home. If you’re calling something tactical, you’d better have a date on the books as to when the solution will be replaced. That’s not easy to do, especially considering how long the typical IT project takes and when funding decisions are made. I had one project where I went to my supervisor and asked him, “Are you okay with paying $$$ for this now, knowing that we will replace it in 18 months to 24 months?” He said okay, and while the real timeline wound up being about 36 months, the replacement eventually did happen. That’s probably the closest I’ve come to truly having a tactical solution. At the time the solution was put in place, a placeholder was put in place for the strategic solution and the process for obtaining funding began.

This brings up a great point for the domain of enterprise architecture. Many architects out there spend a lot of time establishing a “future state architecture.” Often, the future state is a pristine of view on how we want things to be. What doesn’t happen, however, are statements regarding everything that exists today. I’m a big fan of making things as explicit as possible. When I’ve worked on future state architecture, I always ask about the current platforms and what will happen to them. Either they’re an approved part of the future state (and they can be classified as not available for new solutions), or there needs to be a project proposed to migrate to something that is approved. What you don’t want to do is leave something in limbo where no one knows whether it’s part of the architecture or not. The same holds true for so-called tactical solutions. Unless there’s an approved project to replace it with the strategic solution, it’s not tactical, it’s the solution. Don’t let it linger in limbo.

The SOA Consortium has launched a blog, SOA Consortium Insights. Check it out. For those of you that aren’t members, it will give you an easy way to keep up with the ongoings of the Consortium. The latest entry discusses Richard’s experiences at TechTarget’s CIO Decisions Conference and Gartner’s Application Architecture, Development, and Integration Summit.

I had a doctor’s appointment today, and in the office, they had a poster asking their patients for patience as they work to implement electronic records. The signs have been up for the last few visits, so I think the bulk of the efforts are complete. From an experience standpoint, I’m very satisfied.

When the effort first started, one of the first things they did was take a digital photo of me at my next visit. In addition to the office staff now recognizing me when I come in the office, I personally feel that this has greater potential for reducing errors. Why? Every staff worker that’s not permanently seated at a desk is carrying around a laptop (Fujitsu Lifebook, I believe). When they are dealing with patients, they should be seeing my smiling face as they enter in various information. That provides a constant reminder of who they’re working with. When dealing with paper files, there’s a risk that someone gets them mixed up, and the people using them don’t realize it. While I’m sure this is a very infrequent occurrence, it’s still possible, and having the person’s photo there the whole time should reduce those occurrences even more.

With today’s visit, the cool thing that happened is that my doctor needed to issue a new prescription, and she simply typed into her laptop and told me it would be at the front desk. When I went to the front desk, they handed me a printout, but also indicated that the printout had already been faxed to my preferred pharmacy. Cool.

Overall, I like what it has enabled. The thing that stood out like a sore thumb, however, was the dependency on the FAX machine. They communicated with my pharmacy via FAX. They issue requests to the lab downstairs via FAX. It would be great if some standards could exist so that the doctor’s systems are directly communicated with the pharmacy network or the laboratory. While the electronic prescription FAX has the medication printed in a nice 14 point serif font, it still gets turned into a bitmap, spat out on a sheet of paper, and interpret by some pharmacy technician. From my standpoint, I’d prefer that the doctor’s office talk directly to the pharmacy’s information systems to make this happen and take as much human element out of it as possible. I’d rather have the pharmacist talking to people about their medications than having to interpret doctor’s handwriting or some poor resolution fax.

The other piece of this that could be improved is to provide a secure way for me to get at the information. Suppose you get a cholesterol test. Often times, the doctor may just tell you, “you’re normal.” Typically, however, it’s important to look at trends. (Aside: Yes, just as you should be looking at the metrics of your IT systems and associated trends when things are working fine, you should be looking at your own metrics and trends for your own physical health!) To look at trends, you need the actual test results. Today, I have to call up and have someone read them to me. It would be far more convenient to have some secure electronic way of accessing it. It’s especially true when you’re dealing with multiple doctors. They have a major data synchronization problem, where the patient is viewed as the authoritative source, but often times, we don’t have all the information because our doctor’s haven’t given it to us, or if they did, it was 6 months ago. How many of us have our own medical record keeping system?

Anyway, kudos to my doctor for trying to push the envelope a bit and leverage technology. Here’s to hoping the trend continues.

The Mac developer community has been abuzz with Steve Jobs’ announcements regarding development for the iPhone. In short, he told the development community to leverage the web. He specifically mentioned AJAX, which points to a model like Apple’s Dashboard Widgets: Dynamic HTML + CSS + AJAX. If you’ve ever tried Widget programming, or Vista Gadget programming for that manner, while the bulk is Dynamic HTML + CSS + AJAX, there are a small set of native APIs exposed that provide some necessary capabilities such as saving preferences. The question that wasn’t answered in the Keynote was whether such an API will exist for the iPhone. Clearly, there are concerns about security that must be investigated. Steve mentioned having the ability to place a phone call. It could be very dangerous if you go to a website and through JavaScript it starts sending SMS messages or making phone calls. A no-API solution would be more client-driven, where the iPhone would recognize that a phone number is displayed in a widget and give the user the option to call. Off the top of my head, I can’t think of anything where I’d want a program doing those things for me.

Given this, is the lack of a distinct API a big deal or not? My opinion is that it isn’t. Why? The biggest reason is that the iPhone is not a general purpose computer. It’s three things according to Steve: a phone, an iPod, and an Internet Communicator. On the phone side, it already provides everything needed for making calls, so no big deal there. On the iPod side, same thing. On the Internet Communicator side is where the debate comes into play. Or does it? Being an Internet Communicator these days is typically concerned with being a Web Communicator, and since the iPhone has a real web browser, not WAP, doesn’t it provide everything we need (except Flash support)? I’ve previously posted that I think we’ll be seeing more and more lightweight widgets with rich UIs available via web technologies. It would seem that these types of solutions are very well suited for a mobile device like the iPhone. I’m not one of those people who needs Microsoft Word or Excel on a small handheld device. There are developers who may be annoyed that they won’t have APIs for direct access to the Multi-touch interface, but I would argue that’s Apple’s problem, not theirs. How many applications are being written that need a new keyboard or mouse? There’s only one category that I can think of, which should be the only area upset with the announcement: games.

For as long as I can remember, there have been continued evolutions in game controllers. The original joystick of the Atari 2600 is not still in use on today’s Playstation or Wii. So, it’s very conceivable that game developers could find some cool way to leverage the multi-touch interface. Secondly, the size and form factor of the iPhone is well-suited for gaming. Apple even knows this, as they opened up the iPod for games some time ago. Let’s remember, however, that Apple does not allow anyone to produce games for the iPod. I would guess that this is necessary to ensure the security of the iPod is maintained. While an iPod can’t go calling someone, would you be happy if a game wiped out your contacts, songs, or videos? It’s entirely possible that it could also be used to transfer a worm/virus via iTunes synchronization. So, to maintain the “Apple experience” it has to be a tightly controlled environment. With the connectivity of the iPhone, this is even more important. While the same challenges face other mobile phone providers, none of them rely on experience to the extent that Apple does. It’s part of their corporate image, and it’s not something they’re going to bend on. Given that Apple has a partner ecosystem for iPod games, I’m sure the same thing will happen for iPhone games. Given that, I think Apple’s done exactly the right thing. The only thing they need to provide is the iPhone Dashboard. I don’t want a Safari bookmark for every iPhone Web 2.0 app, I want the phone to manage it just as Apple’s Dashboard does with its widgets today. Who knows… perhaps that’s the mysterious 12th icon. I hope to find out in two weeks!

Update: I forgot to discuss the whole Safari on Windows thing. The discussion from Dan Farber at ZDNet made me think of it. My opinion is that it must be a developer play. If the route to the iPhone is through the creation of Dashboard-like widgets, and the underlying CSS engine is Safari, developers have to have a tool for testing it. Starting with the Mac, the first tool for this was Safari. It was only later that Apple came out with Dashcode. I’m guessing that it was probably a far easier path to take Safari to Windows than it would have been to take Dashcode.

Update #2: There’s another discussion on this from Patty Seybold at her Outside Innovation blog.

Just a quick plug to let my blog readers know that I’ll be part of a panel discussion on SOA trends at The Open Group Enterprise Architecture Practitioners Conference on July 23rd in Austin, TX. The panel will be moderated by Dana Gardner. In addition to myself, the panelists are Eric Knorr of InfoWorld, Tony Baer of OnStrategies, and Beth Gold Bernstein of ebizQ. You can register for the conference at http://www.opengroup.org/austin2007/register.htm. If you’re there, please feel free to introduce yourself, ask questions, etc.

The Dilbert for Tuesday, June 12th was certainly appropriate for any conversation on Governance. In all seriousness, however, if you governance processes resemble this, you’ve got problems.

Back in January of 2006, I had a conversation with Phil Windley on governance for an article in InfoWorld. One of the points that I made was that you do need to get your policies documented and communicated. If the only way someone knows whether the decisions they make are right or wrong is by attending a meeting and hoping someone with authority (if they even know who that is) agrees with them, that’s not good governance, albeit it is governance.

The Dilbert cartoon is titled, “CEO Visit.” Clearly, no one will question the authority of the CEO. So, you could argue that step one of governance has been handled, which is establishing the authority of the people who will govern. It’s not just the CEO, but the CIO, CTO, Chief Architect, etc. The problem doesn’t normally exist with authority at these levels, but at the levels in the middle. The chief architect may be signing off on all policies, but they’re probably not setting every policy. There needs to be a hierarchy of decision making, so that decisions are made at appropriate levels, and only where conflicts arise do things bubble up. The problem with this is that if the policies and guiding principles at the higher levels are not established, everything breaks down at the lower levels, because no one knows who has authority to set direction in which area. As a result, people are constantly pushing the boundaries and trying to gain power and influence, rather than actually creating good solutions. It’s not about doing the right thing, it’s about doing my thing. If no one (with authority) has stated what the “right thing” is, individuals will always think that their thing is the right thing. Step two is about establishing and communicating policy.

In a bit of irony, the CEO in the Dilbert makes the statement, “Opinions are treason.” I hadn’t thought about it at the time, but opinions are the downfall of the enforcement portion of governance. Opinions are good when policies are being established. Opinions are bad when policies are being enforced. Think about it. It’s not going to do a bit of good to tell the police officer, “Sorry, I was speeding because I feel the speed limit should be 20 miles per hour higher on this road because of the light traffic and the limited number of entrances, exits, and intersections.” When that highway is being constructed, however, and speed limits are being established, bring all the opinions you want (although backing them up with facts is even better).

We can’t forget about the process (step 3), however. If you employ architecture reviews, what happens all too frequently is that at the time of a review, the discussion turns in a debate of opinions, which will normally go unresolved unless someone in the room is in a position of authority recognized by all. A review needs to demonstrate that policies have been followed, and where they have not, focus on the reasons why an exception is necessary, not on whether it’s a bad policy. In addition, the review must also address areas where better guidance was needed, so new policies can be created. Ask the question, “In coming up with the solution architecture, where did you have multiple options for which the reference architecture and patterns did not provide sufficient guidance? What factors led you to choose the option that you did?”

So, as I’ve said before, governance is about people, policies, and processes, in that order. Without clear understanding of authority, documented and communicated policies, and processes to keep improving things, you’ll wind up going to your CEO far too many times for decisions until he starts calling you “Doofy.”

I’m listening to Dana Gardner’s SOA Insights podcast here at the airport. This episode is a discussion with The Open Group about their Enterprise Architect certification. One of the initial questions was whether the role of the SOA Architect was any different from the role of the Enterprise Architect. It seemed that the group in the discussion all agreed that an SOA Architect was a subset of the overall Enterprise Architect role. What did surprise me, however, was the debate on what the responsibilities of the SOA Architect are.

In retrospect, I shouldn’t have been surprised as the same debate is prevalent in Enterprise Architecture as a whole. I’ve worked with organizations whose view on Enterprise Architecture was that it was strictly a technology play, focusing on standard infrastructure. In the SOA space, this is concerned with connectivity between consumers and providers, dealing with the nebulous world of the enterprise service bus, SOA appliances, web services management systems, etc. as well as the technology used to build and execute services, including application servers, orchestration engines, and the like. While less common (but certainly not uncommon), I’ve also encountered organizations where Enterprise Architecture was much closer to the business, including tasks such as business process modeling. Here, it’s much more about the application of technology, rather than the technology itself. Once again, looking at this from the SOA space, the focus would be on the services themselves, not necessarily on the technology used to expose them. What’s my opinion? Simple, it’s both. The only debate is on what is the appropriate organizational structure is for these roles and responsibilities. There’s always some subdivision of responsibilities across multiple people. A topic such as middleware technologies has enterprise applicability but sufficient breadth within it given the continuing evolution of development technologies such that you can have a full time architect focused on the strategy around it.

Regarding whether EA should also include the application of the technology, this was a nice lead in to a second point of debate, which was whether a developer background or a business analyst background leads to an EA career path. Again, I think the right answer is both. A business analyst background will pay significant dividends toward the component of EA concerned with the application of technology, although it depends on how much your analysts participate directly in the technology application efforts. While I do think there’s more potential for some with a technical background to become an EA, simply because of the breadth of solutions to which technologies like Java EE or .NET can be applied, there’s far more value in combining that with business knowledge. Furthermore, the further you go on the business side, the more likely that the role of strategic planner for the business is already being covered by someone on the business side. Those people need to be actively working with EA.

The final point of discussion was around the role of education in Enterprise Architecture. The panelists all agreed that experience was a critical factor, and that you can’t teach experience, however there are aspects that can be taught. One panelist gave the example of a course on TOGAF. The one subject that didn’t come up in this or the discussion around the career path to EA was the ability to be a big picture thinker. For me, this is a must have for anyone in the EA role. Enterprise architecture is about the enterprise. If you can’t see the forest for the trees, you’re going to struggle. If you look at the typical IT organization, what’s the percentage of people who are working on project efforts that are narrowly defined? I’d argue that it is well over 50%. Take out the support and overhead activities, and you’re not left with much. Therefore, EA has to fill that strategic planning gap. You need to be comfortable in working in areas where boundaries are fuzzy, if they’re even known at all. Conflicting priorities and politics are the norm. Personally, I think being a big picture thinker is extremely difficult to teach. I think people naturally prefer to focus on either the details or the bigger picture. I focus on the big picture. As an example, my wife and I are redecorating our front room. She painted everything, and then went out and bought a bunch of artwork for it. She and her mother were hanging the artwork and she asked me to come up and offer my opinion on whether the piano should be moved six inches to the left or not. I told her that it all depended on where the artwork was going to be placed and the balance of the room. I couldn’t offer an opinion solely on the piano, I could only offer an opinion whether considering the entire room. I think I even said that moving the piano six inches was insignificant. Someone who is detail oriented probably would have obsessed over those six inches.

There are risks associated with being a big picture thinker, and it’s important that your EA staff recognize it. Strategy is useless unless you execute. This doesn’t necessarily mean going deep into the details, but it does mean that you need to come up with a logical sequence of activities that can realize the strategy. With each activity, however, you’re narrowing the scope so that you can now leverage the other 90% of the organization that is focused on refining scope and making it happen.

Courtesy of Rich Seeley and SearchWebServices.com, I caught up with the recent announcement from IBM Rational at their IBM Rational Software Development Conference going on in Orlando.

Rich paraphrased David Locke, director for IBM Rational Worldwide Marketing Strategy, stating that “the next generation tools that the Jazz project is expected to create will aim at providing real-time collaboration of geographically dispersed project teams through things like embedding instant messaging technology into development tools.” There are a few things that occurred to me after reading this.

First, the idea of “open commercial” is quite interesting. IBM Rational still intends to develop “fully commercial” products, yet they’re doing it through a very open process. As long as the community doesn’t revolt on them for wanting their time without somehow sharing the profits, this could be successful. While I’ve never seen studies on it, I still suspect that the bulk of open source products are still strongly subsidized by paid staff of companies that are making money from it (e.g. IBM, MySQL). I’m sure IBM and BEA both have paid staffers who spend all of their time on Apache projects.

Second, the mention of instant messaging brought up recent memories for me. While I don’t think anyone has noticed, there’s a link at the top of this blog labeled “Talk to Me”. As an experiment, I put a Google Talk widget on the site. Unfortunately, it doesn’t work the way I’d like it to. Effectively, I wanted it to be pre-configured with a buddy list of me, without the ability to chat to anyone else, or maybe just to people visiting my blog. There wasn’t a way to do it. I looked into other systems, but didn’t find a way to integrate with my existing IM clients. To make Google Talk work, I had to post instructions on adding me to the buddy list, which isn’t that great of a solution. Anyway, my point with all of this is that it’s a big challenge on figuring out how to integrate all of these things. I was listening to the latest Monkcast from ZDNet and Redmonk and listening to the guys reminisce that at one time years ago, Microsoft Exchange was winning because of its simplicity. I will certainly agree that keeping things simple can be beneficial, but eventually there becomes a need to integrate all of these smaller, simple items into something that is more functional and efficient. Balancing those tradeoffs is not an easy problem. Here again, I think there is power in the masses and opening it up to the community. The last thing we need is an embedded and isolated IM client, and that’s just one example. Personally, I hope that the community looks into some of the lightweight capabilities provided by things like the MacOS X Dashboard and Vista Sidebar and see if we can get the simplicity of these low-functionality interfaces but yet allow “right-time” integration with the tools we’re using the majority of the time.

Jordan Haberfield of Excel Partner recently posted a blog titled “Enterprise Architects as ‘Impact Players'”. I’ve enjoyed Jordan’s blog as it discusses EA from a different perspective, one of talent and corporate culture, rather than the technical aspects. I’ve always found the human and social aspects of things very interesting.

Anyway, he provides an excerpt from a book he read called “Don’t Send a Resume: And Other Contrarian Rules To Help Land A Great Job” by Jeffery Fox which introduces the role of the impact player. Here’s the quote:

“There is always a job in a good organization for an impact player. An impact player is someone who can quickly improve the economics of a company. An impact player is someone who can bring in customers, energize the sales force, restructure an under-performing department, speed up the innovation process, solve the late shipment problem, or physically move the manufacturing facility to a lower cost area. An impact player also is someone who will do the necessary but noxious tasks no one else wants to do. An impact player is someone who will get their hands dirty, pick up a shovel and start shoveling, open the store early and close late, deliver product on their way home, deal tirelessly with irate customers and make a service call on Christmas Eve. Good executives in good companies want to hire impact players.”

Jordan goes on to state that “Enterprise Architects are in a position to become that impact player and make a significant difference.” It’s probably better stated that Enterprise Architects should be in a position to do this. Whether they are or not is highly dependent on the corporate culture.

I’ve spoken with a number of colleagues in the St. Louis area, and it’s my understanding that many of the organizations here where I reside don’t even have a formal EA group. Why is this important? It’s important because I believe that an impact player often has to transcend boundaries and operate outside of the constraints that a particular job description may imply. If an organization doesn’t have an Enterprise Architecture discipline, someone needs to go outside of the box of their current job description and start doing EA. If the corporate culture is resistant to people operating outside of their formal job description, that impact player is going to need some very thick skin.

A great example is from two years ago when Jason and Ron at ZapThink emphasized the need for the SOA Champion to guide an organization through SOA adoption. SOA is not about buying an ESB, Registry/Repository, or any other tool. For the bulk of companies that comprise the “status quo” of Service Averse Architecture, it’s about a fundamental change to the way IT solutions are delivered which can cover organizational change, process change, and technology change. What organization has a formal role established for this position? Probably not many. It requires someone to be an impact player, think outside the box, transcend boundaries, and pave the path for the new way of doing things.

Some companies encourage individuals to think outside of the box and outside of their formally stated responsibilities, and it’s probably one that should be added to the litmus test for a company likely to be successful with innovation and strategic initiatives. After all, the degree to which a company does this is a matter of trust. Unfortunately, it’s far easier to break down that trust that it is to build it up. For those of you dealing with that, follow this link to another excellent book that I’ve read.

In summary, the original quote by Dr. Fox states that “There is always a job in a good organization for an impact player.” The key part of this is “good organization.” If you are exhibiting the qualities of an impact player, but you’re struggling to be successful, take a look at the organization’s culture and see whether it is a “good organization” or not. If you’re looking for a good organization, you may need to look for the foot-in-the-door opportunity, because often times, it takes an outsider to come in and recognize the areas for potential impact, so you’re not going to find it on Monster or Dice.

One of my colleagues at MomentumSI, Jason Henley, has begun blogging on SOA and other things of interest to him. Give his blog a read.

James Governor of RedMonk has a post that he claims is the “Most exciting idea in ages: an ATOM/LDAP mashup.“ It’s actually a very interesting idea to me, especially because he suggests applying it to the management domain. I’ve previously posted (here and here) about the convergence of metadata, and how I’ve seen parallels between Service Repository, Configuration Management databases, Asset Management systems, and potentially even LDAP. So, if we’re doing an ATOM/LDAP mashup, is ATOM equally applicable to other items in the metadata management domain. I suspect that it will be. Nearly all management specs I’ve seen have a resource-oriented view, and it would seem that the combination of ATOM and REST could be a very good fit on top of this. Hopefully James will keep us all updated on the progress of this exciting idea.

As another example of innovative thinking and how we should look “outside the box”, take the recent entry by Vinnie Mirchandani entitled “People! More Government is Not Good!” While by the title you might think it is a political commentary (which it partially is), it begins with a discussion on compliance IT. Vinnie further uses real world examples of government activities versus activities in the private sector, such as Wal-Mart’s response to Hurricane Katrina as quoted from Fortune:

That was Hurricane Katrina, when government at nearly every level looked utterly incompetent while businesses became the heroes. FedEx delivered 440 tons of relief supplies, mostly at no charge. Wal-Mart meteorologists informed managers that Katrina was headed for New Orleans more than 12 hours before the National Weather Service told the public; the company later hauled millions of dollars of supplies into the worst-hit areas days before FEMA showed up.

It is posts like these that keep things interesting for me. By looking at how governance operates in non-IT scenarios, there are lots of lessons that can be learned on how to apply it within IT scenarios. SOX was intended to bring a new level of compliance and accountability to businesses. Will SOX bring back credibility and trust or is some form of self-regulation more important? How does this apply to the context of SOA governance? One key difference is that businesses already had governance prior to SOX, especially for public companies. On top of that, there is the notion of business ethics. In contrast, the more people I talk to, the more I think that the majority of organizations have little to no technical governance. So what’s the right approach? While businesses may not have needed more governance, it’s hard to argue that for IT. In a culture that lacks governance, can they be trusted to self-regulate? One thing is for sure, it won’t happen if there isn’t a shared understanding of what the right thing is. Perhaps the message should begin with one of SOA ethics and morality and then move on to SOA governance. Ethics and morality establish the unbreakable principles of the society as a whole. Communities that agree on these principles can be very successful with self-regulation and less governance. Communities that do not are unlikely to be successful with self-regulation. Where does your IT department stack up? Are there unbreakable principles that they all agree on?