It is both. SOA governance is not much different than any other kind of governance in an organization. Successful SOA governance cannot be achieved without people framework. Socioeconomic factors such as organizational dynamics (I think it is a good synonym for politics) drive the SOA strategy for an organization.This is especially true for IT organizations where the organizations are on the supply side of SOA for their product offerings. Many people miss the fact that the governance efforts are not only limited to the internal employees in an organization but are typically extended to customers and partners. Many organizations co-innovate with customers and partners and these partners and customers significantly influence the SOA governance policies of an organization.
Many architects view SOA governance as a technical challenge, but I beg to defer. Strategic SOA governance is not just a technical problem; it is a business and process problem that has socioeconomic implications. I already talked about the people part. Talking about SOA economics, there is no good way to calculate ROI based on just SOA. Few people have actually tried doing this and I am not sure if this is a right model. Number of services or number of reusable services or any other QoS for SOA don't help to build an economic metrics. SOA is quite intertwined with the business and it is your guess versus mine in extracting a monetary value out of it. Having said this, people do work hard on making a business case for their organizations since SOA is hard to sell.
The strategic to tactical transformation of SOA is not easy. This is where people argue on several reference architectures, policies etc. These are very time consuming and dirty efforts and include several technical, domain, and functional discussions. Cross-functional team works well to tackle this kind of governance problem since it is critical to have a holistic (horizontal) view of SOA with enough help from the experts in several (vertical) areas. SOA architects have to have good people and project management skills since as I already mentioned governance is not just a technical problem. If you are a technical architect, you end up with a diagram like this. This diagram does not help anyone since it mixes a lot of low level details with high level details and the information is difficult to consume. Communicating the architecture is one of the difficult challenges for an architect and it even becomes more difficult if you are describing strategic SOA governance.
Sunday, June 17, 2007
Monday, June 11, 2007
Visual Design versus Interaction Design
I have seen and participated into this debate many times - what design we should tackle first, visual or interaction? There is no one answer, but here are some thoughts. What we really need is a good framework in place during the design phase before we work on the details of any of these designs. The actual design cannot be accomplished until we have idioms, metaphors (for interaction design) and brand, visual theme (for visual design) etc. flushed out and agreed upon.
One designer describes visual design as skinning the wireframes to prevent the end of wireframes and hence death of interaction design. This is a bit extreme and many visual designers won't be thrilled with this opinion. Wireframes are good tools to document interactions and to get a quick validation via cognitive walkthroughs. Visual design is horizontal and it should be made sure that it is consistent across all the parts of an application so that they have the same visual appeal. Interaction design is vertical and could describe some very specific interaction scenarios for each set of pages.
Users would however recognize the visual design appeal first and may not even have direct appreciation for good interaction design until they figure out they can accomplish everything in an application without putting in a lot of thoughts. The visual design is easy to demonstrate than to document it and that's why people jump to photoshop since transformation of visual artifacts from photoshop to actual web-based application is not that difficult. On the other hand interaction design deals with data, user's intents and actions, feedback etc. There is no one-one relationship from wireframes to the actual screens but having detailed wireframes help developers establish good understanding of the interaction model and designer's expectations. We highly encourage that designers co-locate with developers but if that's not the case, especially for remote teams, documenting design is critical.
I am not trying to downplay the role of visual design - it is the "look" part of look and feel and it's not just about the skinning of wireframes. Visual designs need their frameworks too such as CSS, typography, symmetry, balance, etc. but there are many ways to slice and dice time on interaction and visual design in a project - these are not the alternatives at the same level. I don't want to stereotype developers, but most of the developers think that the only design that they need is visual design and not the interaction design since the discipline of interaction design is less known in the developer community. Alan Cooper's work, especially "The inmates are running the asylum", describes this conflict in detail. Developers follow "system model" as described by Don Norman which is essentially an implementation centric design. Designers should make every possible effort to document and emphasize the interaction design to achieve overall user experience. The visual design is, well visual, and developers are more likely to embrace it or even ask for it.
One designer describes visual design as skinning the wireframes to prevent the end of wireframes and hence death of interaction design. This is a bit extreme and many visual designers won't be thrilled with this opinion. Wireframes are good tools to document interactions and to get a quick validation via cognitive walkthroughs. Visual design is horizontal and it should be made sure that it is consistent across all the parts of an application so that they have the same visual appeal. Interaction design is vertical and could describe some very specific interaction scenarios for each set of pages.
Users would however recognize the visual design appeal first and may not even have direct appreciation for good interaction design until they figure out they can accomplish everything in an application without putting in a lot of thoughts. The visual design is easy to demonstrate than to document it and that's why people jump to photoshop since transformation of visual artifacts from photoshop to actual web-based application is not that difficult. On the other hand interaction design deals with data, user's intents and actions, feedback etc. There is no one-one relationship from wireframes to the actual screens but having detailed wireframes help developers establish good understanding of the interaction model and designer's expectations. We highly encourage that designers co-locate with developers but if that's not the case, especially for remote teams, documenting design is critical.
I am not trying to downplay the role of visual design - it is the "look" part of look and feel and it's not just about the skinning of wireframes. Visual designs need their frameworks too such as CSS, typography, symmetry, balance, etc. but there are many ways to slice and dice time on interaction and visual design in a project - these are not the alternatives at the same level. I don't want to stereotype developers, but most of the developers think that the only design that they need is visual design and not the interaction design since the discipline of interaction design is less known in the developer community. Alan Cooper's work, especially "The inmates are running the asylum", describes this conflict in detail. Developers follow "system model" as described by Don Norman which is essentially an implementation centric design. Designers should make every possible effort to document and emphasize the interaction design to achieve overall user experience. The visual design is, well visual, and developers are more likely to embrace it or even ask for it.
Saturday, June 9, 2007
Apple and Google alliance
Few bloggers have picked up this Wired's post on a speculation of Steve Jobs announcing a possible alliance between Apple and Google. Interesting - that's all I can say. The post has a quote from Eric Schmidt that Apple actually gets the design but does not have the necessary computing infrastructure. I agree. Apple is a company that delivers innovation with heavy focus on design (of all kinds) where as Google has brought in simplicity and agility by nailing down few very simply problems with state of the art technology innovation. Google certainly does not have bad design but Google has a long way to go and has plenty of opportunities when it comes to interaction or visual (sensory) design. I was told that the person who leads the user experience efforts at Google has "office hours" during which developers can (and do) drop in and expect that person to solve design problems. This was quite a challenge for that person since the design process does not quite work that way. On the other hand, design is one of the biggest strength that Apple has and given the computing resources Apple can do miracles. I don't think it is about or limited to .Mac. iTunes can have a great story if offered on Google's cloud since it could have great sharing and preview potential with Google's cloud. Apple did have issues with iTunes after last Christmas when people started using their iTunes gift cards to buy music and the store could not handle those concurrent users. It was a true load test and iTunes did not do well. Imagine the same scenario - iTunes running on Google's cloud and tightly integrated with AdSense. YouTube is a great platform for video syndication with a community angle. Apple does have community but the syndication is limited to downloading and does not have sharing semantics. Having said this despite of these product synergies an alliance cannot be successful unless it can offer a tangible business value. But hey, this is a speculation, isn't it?
Friday, June 1, 2007
Moore's law for software
Software design has strange relationship with the computing resources. If the resources are low it is difficult to design and if the resources are in abundance it is a challenge to utilize them. It is rather odd to ask the designers and developers to have Moore's law for software, but this is true and it is happening.
The immense computing resources have opened up a lot of opportunities for the designers and developers to design agile and highly interactive web interfaces by tapping into this computing cloud. Effective resource utilization by software is by far lagging the fast growing computing resources. Google has successfully demonstrated a link between the humongous cloud infrastructure and the applications that effectively use these resources. Gmail and Google Maps are examples of agile and highly interactive interfaces that consumes heavy resources. Google's MapReduce is an example of effective utilization of the computing resources by designing the search to use heavy parallelization. One of the challenges that designers face these days is to be able construct an application from an interaction perspective such that it can actually use the available resources effectively to provide better use experience. Traditionally the performance tuning is all about fixing software to perform faster without adding extra computing resources. The designers and developers now have a challenge to actually use the resources. The cloud computing is going to be more and more relevant as various organizations catch up on Web 2.0 and Enterprise 2.0. Google, Yahoo, Salesforce, and Microsoft are betting on their huge infrastructure that can deliver the juice required for their applications. Cloud computing is not just about hardware - it is about the scale of computing and the infrastructure that is required to get to that scale such as physical location, energy and cooling requirements, dark fiber etc.
Not every single piece of code in software can be parallelized. Developers hit a set of serial tasks in the code flow for many dynamic conditions. Semantic search is a classic example that has many challenges to use parallel computing resources since you do end up serializing certain tasks due to the dynamic nature of many semantic search engines and their abilities of natural language processing. Cognitive algorithms are not the same as statistical or relevancy algorithms and require a radically different design approach to effectively utilize the available resources.
Intel has been pushing the industry to improve performance on its multi core CPU . Microsoft recently announced an initiative to redesign the next Windows for multiple cores. The design is not just about one, two, or three cores. The resources are going to increase at much faster pace and software designers and developers are late to react and follow this massive computing. Computing in a cloud requires a completely different kind of approach in software design and there are some great opportunities to innovate around it.
The immense computing resources have opened up a lot of opportunities for the designers and developers to design agile and highly interactive web interfaces by tapping into this computing cloud. Effective resource utilization by software is by far lagging the fast growing computing resources. Google has successfully demonstrated a link between the humongous cloud infrastructure and the applications that effectively use these resources. Gmail and Google Maps are examples of agile and highly interactive interfaces that consumes heavy resources. Google's MapReduce is an example of effective utilization of the computing resources by designing the search to use heavy parallelization. One of the challenges that designers face these days is to be able construct an application from an interaction perspective such that it can actually use the available resources effectively to provide better use experience. Traditionally the performance tuning is all about fixing software to perform faster without adding extra computing resources. The designers and developers now have a challenge to actually use the resources. The cloud computing is going to be more and more relevant as various organizations catch up on Web 2.0 and Enterprise 2.0. Google, Yahoo, Salesforce, and Microsoft are betting on their huge infrastructure that can deliver the juice required for their applications. Cloud computing is not just about hardware - it is about the scale of computing and the infrastructure that is required to get to that scale such as physical location, energy and cooling requirements, dark fiber etc.
Not every single piece of code in software can be parallelized. Developers hit a set of serial tasks in the code flow for many dynamic conditions. Semantic search is a classic example that has many challenges to use parallel computing resources since you do end up serializing certain tasks due to the dynamic nature of many semantic search engines and their abilities of natural language processing. Cognitive algorithms are not the same as statistical or relevancy algorithms and require a radically different design approach to effectively utilize the available resources.
Intel has been pushing the industry to improve performance on its multi core CPU . Microsoft recently announced an initiative to redesign the next Windows for multiple cores. The design is not just about one, two, or three cores. The resources are going to increase at much faster pace and software designers and developers are late to react and follow this massive computing. Computing in a cloud requires a completely different kind of approach in software design and there are some great opportunities to innovate around it.
Subscribe to:
Posts (Atom)