Note: You are experiencing only the raw content of this site, without the intended layout and design. Either your browser has ignored the Cascading Style Sheet (CSS) files for this site, or you are using an outdated browser which does not support Web Standards. Learn more.

Home « Blogs

EDS' Next Big Thing Blog: Read and Respond to What the EDS Fellows Say About Technology

Read and respond to what the EDS Fellows have to say about the future of technology on EDS' Next Big Thing Blog on eds.com.

February 2008 - Posts

Location awareness -- the tip of the iceberg

Last week I was talking with Vinnie Mirchandani about the impact of all the sensor information coming into the enterprise in the near future. What the effect will be on ERP systems...

This week I saw an article in information week about the same subject. As sensor use enters into the enterprise, they'll provide much more context of the enterprise. Efforts like unified communications provide more information about the context of the individual. This will enable a next generation of the enterprise.

We're going to see the need for smarter systems, just to enable the decision making process. When we're talking about terabytes of data per hour flowing into large enterprises, people just don't work with that volume of information.

Geographic information can provide a key role in assisting with the contextual intersection between the employee and the enterprise, limiting the flow of information to only those who can do something about it. Since more phones will have GPS capabilities, the balance between personal privacy and corporate information overload is a battle that is about to commence.

For the public, there is already a great deal of discussion about correlating information across all the other sensors in the environment enabling a real life recorder capability. In the UK they talk about having >4 Million CCTV cameras. Many of these now have additional sensors like infrared or built in contextual knowledge looking for illegal behavior. When you add in sensors, the target for London will be millions of sensors per person by 2050.

SOA Governance Is Not IT Governance Reborn

There's been a lot of talk about how SOA should be driven by the business, and the need for SOA governance (e.g., Defining SOA Governance). Unfortunately, SOA governance is typically cast as better IT governance-typically getting the enterprise to invest in SOA technology and to support the development of shared application components.

This assumes that SOA is about technology. It is only about technology to the extent technology enables improved business operations. SOA is about the design of the business.  SOA governance is enterprise governance.

Services are capabilities offered by a business entity and used by another business entity. SOA is "a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains." (see OASIS Reference Model for Service Oriented Architecture). While a capability may be supported by an application, it is also, and more generally, supported by people, skills, data, and other resources that are supplied by non-IT business organizations. The business entities-the ownership domains- need not be independent companies, but may be business units within an enterprise. In some cases there may be no computer application, only services, probably driven by automated business processes.

So SOA governance is about managing business services. Services to customers, services to internal business operations, services to other business partners. Furthermore, in a service oriented enterprise, everything the enterprise does should be characterized as a service.  A business service will typically involve other services directly or indirectly, to maintain its capability and deliver its results. This is where the real value of SOA is, and it is the business value of SOA that should be the focus of SOA governance.

Posted Thursday, February 28, 2008 6:40 PM by Fred Cummins | 0 Comments
Filed under: ,

Morphing phone concept based on nanotech

Nokia has unveiled "Morph" a concept phone based on using nanotechnology capabilities (e.g., shape, color changing). Many times when people hear about nanotechnology they wonder what difference it could make for them personally. The concept video shows how future mobile devices will allow users to modify the device to fit changing situations, conforming to different shapes and functions.

Morph is a joint nanotechnology concept developed by Nokia Research Center and the University of Cambridge and has gone on display as part of the "Design and the Elastic Mind" exhibition at The Museum of Modern Art in New York. This exhibit even has an online component, that is impressive.

IT and Cloud Computing

Rob Preston in InformationWeek had an article titled Will Cloud Computing Rain on IT's Parade. I know the title was just a play on words, but it got me thinking. Why would the IT organization feel threatened by cloud computing? As Rob points out there are many new skills that will need to be developed to take advantage of the new integration and vendor management opportunities. If IT operates the way it continues to work today, sure the number of people to support operations will go down.  On the other hand, the new value generation opportunities for the IT organization should expand significantly. I've mentioned before the increased or changing role of workflow, modeling and simulation can play in improving organizational performance. These will remain highly skilled and high bandwidth roles that will change IT, but I doubt they'll make it significantly smaller in the near term, at least for organizations that view IT as an element of increasing value, and not just a cost to be cut.

Cloud computing (compute as a service), Software as a Service and BPO (service as a service) are all techniques that organizations will need to understand and actively decide their role in the future.

Integration the core of the home of the future

Recently there was an article in Wired Disney Revives 'House of the Future'. If this is anything like Microsoft's home of the future display, I'm sure it will get some people excited.

It does make me wonder how effective for the public this kind of demonstration really is, or is it more marketing than anything else. Almost everything that is on display is commercially available. It has just not been integrated as effectively.

Anyone who watches much HGTV network has seen this kind of integration in homes. The point of the demonstration may be that the capabilities will soon be available at the low end of the market. I wonder who will do the integration. I guess it will have to be your local systems integrator. Just like we have home theater integrators, it will expand out into just home integrators.

Working with big companies

In the past few weeks, there has been a great deal of discussion about what Microsoft or Yahoo will do. It made me think about a blog entry I'd see a while back about the inexplicable behavior of large companies. The entry is well worth reading and uses a Moby Dick metaphor to describe guidelines for a smaller company trying to work with large companies:

  1. don't do startups that require deals with big companies to make them successful
  2. never assume that a deal with a big company is closed until the ink hits the paper and/or the cash hits the company bank account
  3. be extremely patient
  4. beware bad deals
  5. never, ever assume a big company will do the obvious thing
  6. be aware that big companies care a lot more about what other big companies are doing than what any startup is doing
  7. if doing deals with big companies is going to be a key part of your strategy, be sure to hire a real pro who has done it before
  8. don't get obsessed

In the outsourcing business, these guidelines hold true as well.

Posted Tuesday, February 26, 2008 2:00 PM by Charlie Bess | 0 Comments
Filed under:

Grand challenges for Engineering announced by NAE

National Academy of Engineering (NAE) announced the Grand Challenges for Engineering, at a news conference. It is a list of this century's greatest challenges/opportunities. The criteria for selection was to advance how we live "by improving sustainability, health, and joy of living, and reducing vulnerability."

The challenges are:

  • Make solar energy economical
  • Provide energy from fusion
  • Develop carbon sequestration methods
  • Manage the nitrogen cycle
  • Provide access to clean water
  • Restore and improve urban infrastructure
  • Advance health informatics
  • Engineer better medicines
  • Reverse-engineer the brain
  • Prevent nuclear terror
  • Secure cyberspace
  • Enhance virtual reality
  • Advance personalized learning
  • Engineer the tools of scientific discovery

Each challenge has its own page with background materials, references and comment pages.

Currently, the NAE is offering the public an opportunity to vote on which challenge they think is most important and to provide comments at the project Web site, http://www.engineeringchallenges.org/, which features a five-minute video overview of the project and committee-member interview excerpts.

OASIS BPEL4People: Beating a Dead Horse

OASIS recently announced formation of a new technical committee for BPEL4People. WS-BPEL 2.0 (or BPEL for short), the current version, does not address participation of people in business processes. This is one indication that BPEL isn't designed for business users. It's designed for programmers, and BPEL4People won't change that. A true business process language must be designed to represent business processes that make sense for the business and can be, in some cases, implemented manually, as well with a BPMS (Business Process Management System). A business process language also must support SOA (Service Oriented Architecture). As asserted by Joe McKendrick, "BPM and SOA Need Each Other.".

BPEL may be acceptable for specification of processes that are internal to computer systems, but the design of BPEL forces a structure on business processes that is unnatural for business people.  A business process designed by business users must be either constrained or transformed for a BPEL implementation. Today, if a transformed process is presented back to the business users, they probably won't recognize it, even if it is presented in a graphical form rather than the standard XML representation (BPEL doesn't have a standard graphical representation).

In addition, BPEL does not address invocation of independent sub-processes or choreography. These are fundamental requirements for SOA. Use of independent sub-processes allows a business process to use a sub-process that is independently developed and shared with other processes-potentially a shared service. A choreography specification defines an exchange protocol between two or more business entities engaged in a business transaction. Choreography is defined by ebXML BP (also from OASIS) or by WS-CDL (from W3C), but there is no defined relationship between BPEL and either of these choreography languages.  When business entities agree on a choreography, it is important that they have support for designing their internal processes to complement the intended choreography.

BPMN (Business Process Modeling Notation from OMG) was specifically designed for graphical representation of business processes for business people, and it has been widely adopted by the industry. BPMN already has tasks for people and support for independent sub-processes.  BPMN is now supported by BPDM (Business Process Definition Metamodel also from OMG) with a computational model that extends BPMN to address choreography and support enterprise-level modeling of business processes including support for Service Oriented Architecture (SOA).

BPDM defines the integration of orchestration (internal business processes) with choreography (the exchange protocol) allowing each to also stand on its own, so an internal business process can complement multiple choreographies, and a choreography can be supported by different business entities, each with their own internal processes. BPDM with BPMN provide the modeling capability needed to design business processes in a SOA context and with enterprise scale.

Thus BPDM supports the convergence of BPM and SOA that is suggested by Bruce Silver in "The Phony War between BPM and SOA." This convergence will put business people back in control. Bruce notes the discomfort of IT people with the business taking control of its business processes. But it must not stop there; the business also must take control of the definition of services. IT people must support the business in the design of the business incorporating both BPM and SOA disciplines and tools. Those enterprises that realize the synergy of these disciplines and leverage the technology will be able to achieve both the efficiency and flexibility needed to remain competitive in an increasingly dynamic world.

Technical Leadership (part 2) - Communication

After the blog entry the other day, I had a couple people ask me about the role of communications.

One of the issues I've always encountered with technical leadership is the ability communicate technical information to the leaders and followers (the audience). I've always had the problem myself of assuming they're looking at the problem from my perspective. This seems to be a trap that many people fall into. Let's face it, they are not; hey view the problem from their own perspective.

Conveying context is critical, particularly when sending a note to executives, where you want to influence and have them perceive you as having a story they're interested in, your writing style needs to adjust. They are not interested in the details, that's why you're there. If they understood the material the way you do, you'd be working somewhere else. Make communications short and direct. If you can't get it on one page or you can't get the presentation points across in 5 slides, make sure you really know what the audience wants. If it is to an audience of your peers, it is quite a different presentation than to the board of a publicly held company.

For technologist in particular, be careful with acronyms (especially those that are clear from your own contextual perspective). When there is a contextual mismatch, all communications breaks down. If there is too much work for the reader, they'll view it as overwhelming, not derive your points and loose interest.

I'm not saying I can always follow my own advice, but the main purpose of any message is to influence others and the first thing you need to do is get them hooked on what you have to say. You can't brow beat them into submission using a writing style that you prefer. Instead you need to think about how they can and will consume it.  I've had this very conversation with a couple of folks recently. Just because the writer is detail oriented doesn't mean that's what the audience needs or wants to hear, in order to make their decision to support the effort. Changing the writing style will be uncomfortable, but "just get over it". That's why they call it work. ;-)

I'm not an expert or even a good example. There are whole books and professions that focus on this area. Having said that though, everyone though who wants to be a technical leader needs to focus on getting their point across.

Posted Tuesday, February 19, 2008 3:46 PM by Charlie Bess | 0 Comments
Filed under:

A light green activity

EDS has been working with the products of a company called Fifth Light. This company does something that I thought was impossible - dim fluorescent light to improve energy efficiency. There is even a video from the Discovery channel that shows the product in action.

We've got a few of them installed now, and it seems to be a no brainer. Being able to independently address every light in the building would be a powerful energy conservation tool. It will even improve the work environment. I know I'd like the lights in my office to be about half as bright as they are today.

The biggest problem I see with the technology is how to keep track of the address of all the lights. Maybe Bluetooth or ZigBee or even Infrared would be an answer.  The light could broadcast their identity to a relatively small area and you could determine the proper light from there. If you can query the lights status, maybe I could put one in my daughter's closet and make sure the light is turned off after 10 minutes or so.

Technical Leadership

Back in the 80s, I read a book titled Becoming a Technical Leader by Gerald Weinberg (I just noticed that he has a blog on his web page). This book is one I recommend to anyone who is thinking about technical leadership vs. formal leadership. Technical leadership does not seem to be something that is covered effectively by the formal training at any university I've ever seen. Similarly, universities don't really cover the move to formal business leadership either, yet you'll end up in one camp or the other throughout your career.

When talking about technical leadership Jerry states: "Leadership is the process of creating an environment in which people become empowered."

Technical leadership is something that may appear natural, but actually takes a great deal of practice and research. In order to be a leader, you need to have enough context about what is going on to have a vision and then convey it to others. You have to develop enough influence so that others (individual performers and formal leaders) care what you have to say. Technical leadership is more about leading a process than leading people directly. I easily spend 10-14 hours a week researching technical topics, and still feel that is grossly inadequate.

In order to be a technical leader, you need to develop a network of people who will listen to what you have to say and follow. After all a leader without followers is not a leader. Blogging may be one way to do this, but there are many others. The most effective one that works for me is just answering other folk's questions. If enough people feel they owe you, you have some influence; I guess that would be "The Godfather" school of technical leadership. A leader needs to be productive through others and part of that is connecting others together.

Tom Hill, one of the other fellows in EDS, spoke some wise words about technical leadership, they were "Don't discourage them". Meaning: when folks you are dealing with have some wild idea that you really don't understand or you don't think will work, support them, bounce concepts off them, cajole them, but don't ever discourage them. When people are empowered, they feel free to act, ask hard questions and be creative.

Having said that though, a leader does need to have a definition of quality. I've said for years that you demonstrate your definition of quality to others by showing "Quality is what you'll put up with". A technical leader must be able to convey when the results being generated are not up to their standard. Usually this is done through suggestions, and examples. Technical leaders need to have a quiver full of alternatives that they can shoot into the heart of technical activities to make them stronger, not weaker (sorry it's almost Valentine's Day and I had to get a cupid metaphor in there. ;-)

Posted Tuesday, February 12, 2008 4:01 PM by Charlie Bess | 2 Comments
Filed under:

Application portfolio and its value to an organization

One of the critical components of an application management function for an organization is a usable and actively used application portfolio, as part of an overall IT portfolio management approach. It's been widely accepted that 70-80% of any IT organization's budget is consumed in keeping the existing applications running ("keeping the lights on"), yet there are significant technological and regulatory pressures for spending on change.

IT organizations need to shift their perspective to treating the suite of applications supported as an asset that enables the parent organization in meeting their business objectives. These are not just expense items with costs that need to be cut. They are value generation opportunities.

Enterprise IT systems are delivering value to the enterprise - otherwise we should just turn them off. The IT organization need to rationalize their spending and plan for upgrades and investments, otherwise the enterprise will calcify and become fragile, since an upgrade in one area will have a ripple effect on related systems. Solutions that are difficult to maintain and provide little value should be marked for retirement and other options investigated. Hardware that has become too expensive to maintain or unstable need to be replaced. You can't do application modernization without hardware modernization (and vice versa). Probably everyone is aware that this is the way things must work, but there are a surprising number of organizations who don't behave this way.

If the organization does not have a complete list of applications in production, one needs to be created. The system owner and effort expended to keep the systems running needs to be tracked. There are numerous articles and examples available on how to create and the value of application portfolios, so I'll not go into it here. If COTS solutions are involved, the vendors need to be brought into the portfolio planning process, to understand where they are taking their solutions. It's interesting how many times the relationship with COTS vendors become adversarial once the solution is in production. Wait, isn't your enterprise depending on this solution going forward. If you're pointing at the vendor, remember there are three fingers pointing back at you. The first rule of using COTS solutions is to not do anything you know will prevent you from taking the next release - at least not without a very good business reason. I'm not sure there would be a good technical reason.

All client and IT initiated application investments need to go through a governance process, where risks and benefits are assessed against available resources. This process will depend on a viable application portfolio in helping to make decisions. In most organizations, projects consume resources from the same pool. There can't be an underground economy for getting things done.

These application portfolio capabilities, ingrained within an organization's systems development and operations, will provide a firm footing for thought leadership. It should enable the IT organization to take advantage of the capabilities of the rapidly changing IT industry and provide a foundation to influence the enterprise on new ways value can be delivered.

AI - meant for tasks we don't have patience for?

In a recent issue of the futurist there is a set of interviews titled The AI Chaser. This article discussed a number of subtle ways that robotic capabilities are being introduced. I find it interesting that a many of the things discussed or illustrated (e.g., the robotic eaves trough cleaner) are being accepted into people’s lives without any thought about the underlying technology.

The article asks some thought leaders about their perspective on AI and robotic technology on the human condition. Most of them have a very positive view, but there is an edge to most of the visions where there is a loss of or monopolization of technology control. Maybe it is just the recent Sarah Conner Chronicles that is bringing this issue to mind. ;-)

At least for the cases where a country or business, supply and demand issues will enable those who have an advantage to exercise it. Today, it seems that once a technology is known, it is cloned or even improved by someone else in a very short period, so having someone with a long term advantage may not really be too much of a concern.

One of the topics I’ve blogged about before was brought up in the article:

“the advent of AI could allow us to push aside a lot of the tasks that we sometimes don't have the patience for, tasks that are too rigorous or too arduous.”

This perspective is definitely one that most business could use to their advantage.

The 2048 teenager questions the teenager of today

Let’s spin forward 40 years to the year 2048.  Today’s 15 year old teenager is now approaching age 55. The 2048 teenager refers to the 55 year old as “the old guy”. The following is a fictional conversation between the 2048 teenager and “the old guy”.

2048 Teenager    Get real, you actually sent messages on your mobile phone by typing with your thumbs?
“The old guy”     You are right. We typed text messages on mobile phones with our thumbs. In fact, we made up our own shorthand language”. It was pretty cool, since our parents didn’t know what we were saying.
2048 Teenager    Can you tell me some of the cool shorthand words you used?
“The old guy”     Don’t laugh but we used words like LOL, TTFN, and L8R.
2048 Teenager    I didn’t realize that your generation was so cool.

________________

2048 Teenager    Tell me again, why did people send letters by postal mail in 2008?
“The old guy”     This must seem to you like the Pony Express seemed to my generation. Back in 2008 much of the population, especially the older population, did not grow up using computers. Sending letters by postal mail was their preferred method of communication. Around the year 2030 the majority of the population used email like to communicate.
2048 Teenager    Email, what is that?

________________

2048 Teenager    You actually had cables and wires in your house?
 “The old guy”     I realize that today everything is wireless. Yes, the home I grew up had cable for TV and electrical lines for power.
 2048 Teenager   Yeah, I saw that on This Old House. One of my favorite segments is on how to use the old wiring as decoration items.

________________

2048 Teenager    I understand that back in the old days you had to watch TV based on a schedule. We can watch any show, from anywhere, at any time we want to watch it. How did you survive?
“The old guy”     Personally, I survived by using my DVR to record shows and playing them back when I want to.
2048 Teenager    I can’t imagine watching MTV on a fixed schedule. Did you really pay to watch TV?
“The old guy”     It was unfortunate but if you wanted to watch TV other than the local channels you had to pay. We even had to pay for mobile phone usage and to make it worse it was by the minute.
2048 Teenager    You really had it rough in the old days.

________________

2048 Teenager    My history teacher taught us that 2008 was one of the most important points in history is when the world focused on energy conversation. My teacher said that without those efforts we wouldn’t have the comforts that we have today.
“The old guy”     We called the project Green Energy. I have fond memories of that time. In 2008, we focused on switching to environmentally friendly energy. That meant some big changes. I remember my parents selling their gas engine car for a hybrid engine car in 2008. I also remember my parents selling their hybrid car a few years later for a hydrogen powered car.
2048 Teenager    My teacher also taught me that the computer industry had an initiative called “Green IT” to converse energy. Since you are now the CIO of a computer company, I imagine you were part of that effort also.
“The old guy”     Absolutely. Green IT was a challenge throughout the early 2010’s. Today the computer industry is focused on another major challenge “Wireless IT”. Our challenge is to reduce the electrical noise from our wireless communication environment. Hopefully, your generation will have a noise free environment to grow up in.
2048 Teenager    How can I help?
“The old guy”     You can start by turning down the volume in your 567th generation iPod.

Posted Wednesday, February 06, 2008 8:49 PM by Mike Sarokin | 9 Comments
Filed under: ,

Another nanotech roadmap

Foresight Nanotech Institute, a leading nanotechnology think tank, and Battelle, a leading global research and development organization, have officially unveiled Productive Nanosystems: A Technology Roadmap.

This roadmap is an attempt to map out the R&D pathways across multiple disciplines to achieve atomically precise manufacturing. For the past three years, working groups comprised of over 70 research scientists, nanotechnology theorists, and business leaders have collaborated to create a common framework for understanding and defining these pathways.

The proceedings from the nanosystems working group that created the roadmap were released as well. It covers a wide range of topic besides atomic level manufacturing such as: Motors, Movers and applications.

Moving mountains to make mole hills

Almost everyone in the software services space has been involved in situations where heroes stepped up to respond to situations and saved the day. In many cases, the situation could have been prevented. Organizations spend significant amount of resources on processes and appraisals (e.g., CMMI/SCAMPI, ISO 20000) as well as references (e.g., ITIL, COBIT, 6 Sigma) to improve consistency and visibility.

Many times all the effort to create this rigor is spent on the front line workers. The leadership is never recalibrated on using these newly generated work products to assist them in making better business decisions. Yet, isn’t that a significant part of why we’re doing this – to enable better business decisions??

Anyone who’s worked with external development resources can probably identify instances where organizations have stated and can “prove” that they have a level of maturity in a particular area. Yet their record of delivery is not significantly better. I’m beginning to think that rather than looking for just that “certification” (since it is essentially becoming a cost of doing business); I’d use behavioral interviewing techniques on the service organization leadership team to determine how they use the output of their processes to make business decisions. Not just speculation about the use, but specific instances where they made decisions based on the output. Of course, the same behavioral changes will need to take place within the organization requesting the work, since they be receiving work products that may be unfamiliar as well. It does no good to have a situation where you have a thoroughbred pulling an ox cart, or vice versa. We’re all in this together.

I’ve come around to the perspective that if the leadership starts using the deliverables on a daily basis, everything else will come into line. The leadership and customer will have a better understanding of the issues of the day, and be able to focus their efforts on a more proactive basis. Every organization wants and needs heroes, but they should be a second or even third line of defense.

Posted Friday, February 01, 2008 7:14 PM by Charlie Bess | 0 Comments
Filed under: ,

Subscribe to EDS RSS Feeds

I would like to receive the EDS Newsletter