Monday Aug 24, 2009
Cup cakes and bunnies
When I was a young programmer, the key punch ladies used
to make cup cakes for the rest of the IT department. All of us enjoyed
them at morning tea time, as well as the corresponding witty and fun
conversation that was part of that daily ritual.
What happened of
course is that we, being IT, were slowly automating the data entry
processes and no new key punch ladies were being employed, at least
during the years that I worked at the organisation. The ladies used to
remind us, every now and then, that if we worked too hard, there might
not be anything left for them to do. I moved on, into different pastures
and always just assumed that those lovely ladies retired, still happy
(I never did find out, something I must do one day).
This has
always stuck in my mind, that as the technology progresses, the social
and composite nature of teams change, to match the new potential that
has been enabled. As they do evolve, you need to be mindful of people
but you also can't keep delaying change. I don't hear of organisations
now, that still have a separate key punch group, in their IT department.
What about you?
Why don't we have them now? We'll communication
technology has improved and now IT departments are invariably known as
ICT (Information and Communication Technology) departments. The
communication allows once manual processes to be automated. The
internet, allows exchange of information between organisations, so
reports aren't printed in one organisation (or department) that needs to
be re-keyed into a computer in another organisation.
Since the
internet is now becoming mainstream and increasingly being used to
communicate, all sorts of useful knowledge and information, it has
encroached on more traditional means of communication. A companies' web
presence is in many circumstances the first point of call for new or
existing customers. It may no longer be a brochure or some form of
advertising. This has meant that the marketing and public relations
persons, want to ensure that these internet based presences are executed
properly; that is they portray the correct corporate image and
messaging. This isn't an easy task to achieve and if you think about it,
there is potential for tension between the different disciplines.
Over
the last while, social media has come to the forefront. Who should
drive the strategy? Who owns it? What is the nature of the skill sets
required to successfully deliver it? What do you do if someone in your
organisation says something they shouldn't have? (yes, a lot more people
are writing things about or for your organisation)
Well I've
recognised for a while, that you need a composite set of skills spanning
multiple disciplines including marketing to address the aforementioned
questions. Yes, us IT guys now need to work with the marketing bunnies (
a term I use with endearment), copy, usability, graphic designers etc.
All those people that help make the experience better for the consumer
of the medium being used.
Social media is moving rather quickly
now, and I was reminded of some of this potential for tension that has
been rising between the different disciplines as they seek to take
ownership last weekend. I found this blog post "Why
your IT person shouldn't manage your social media!" written by
Diane Lee and as you can see it wasn't IT getting upset at Marketing but
the other way round. It hit a note with me, and I tweeted about what a
Marketing Bunny was saying about the social capabilities of IT persons.
We'll you can tell by the comments on that post, that it hit the same
note with a number of others. However, we were willing to help bridge
these gaps if we saw a sincere apology (the apology happened, can read
the post
here).
Taryn Hicks was concerned about the implications of
the original entry written by Diane and wrote "Why
Marketing and ICT should work together on social media: a response to
mosaic communications". It is well worth reading, as well as the
comments.
only implementing social media, but also with responding to the
implications. There are no text books for where we are going, just
etiquette, common sense and trust through sharing our knowledge openly.
Those that share, are those that are respected by the communities they
are involved in. Those that break the unwritten rules, are given another
chance, as long as things aren't swept away under the carpet. Mistakes
are shown, so that others may learn. Maybe that's where our text books
are now, on the internet, held in conversations on twitter, in online
forums and on blog entries? Continuously being appended to as we learn
more!
Tags control communications it marketing composite social+media | Comments 0
Thursday Aug 16, 2007
Composite SaaS Services - who ownes what?
I've met some interesting people that have great plans to use SaaS mechanisms to provision their software in an Off-premise mode to clients. Its seen as a key way of being able to provide better services to existing customers. The additional benefits would also include more personalised and interactive updates of both application, domain knowledge as well as immediacy of engagement through presence awareness technology.
The interesting point though, is the perceived need to own all IP of the SaaS service, including the provisioning mechanisms.
What I'm working towards is a multi-tenant services with multiple application services, so clear identification of Intellectual Property (IP) is required to enable protection of each parties inventions. It does start to raise a set of interesting issues regarding composite services that comprise capabilities from the provisioning framework, as the applications IP will in all likelihood be dependent on the provisioning framework's IP.
One way I can see to overcome this is to create or use a standards mechanism for SaaS provisioning. However, I have not come across one yet. So if you know of one please let me know?
Tags composite services ip saas | Comments 0
Wednesday Jun 20, 2007
Using Composite Applications to decrease costs
Composite Applications change the game if used properly as a tool to facilitate competition between your System Integration vendors and consultants.
In a traditional project the whole project used to follow a traditional waterfall project methodology, which was fine for the days of COBOL and batch processes. There is a lot of material around that addresses how waterfall methodologies are more akin to engineering techniques then to modern Software Engineering approaches. So I won't go into depth here, describing the differences.
Lets assume that you agree, that more iterative and smaller scoped phases help to reduce risk of overall delivery failure and improve responsiveness to changing business requirements. If you don't agree, email me or even better direct me to your blog, would love to debate this further with you.
I'm a believer, rightly or wrongly, that Portal technology provides a platform to allow for assemble of components into a composite application that reduces the focus from building of a framework to business functionality. That is, Portal technology accelerates the time to value for the business through empowering non-developers to complete the assembly of their environment, to meet the current working context, given that the functionality is available.
So given this, the question then becomes how quickly can the initial framework be deployed and then how quickly can new functionality be delivered that can be assembled into that framework?
The initial framework can be done quite quickly and can be grown - get experienced people and deploy quickly. Too much planning here will not uncover the issues that may be found in your environment, so its best to start doing. This will enable people to start learning about the environment to understand how to start assembling to meet the evolving requirements of their environment. In my view, its knowledge that can only be gained through actual experience.
The second part is additional functionality, so where existing portlets are not available, you will need to have custom portlets and components developed. The beauty of composite applications, is that individual portlets can be wired together to create more sophisticated functionality. This occurs not during development but when the user or an adminstrator decides.
Don't use one organisation to develop your portlets to achieve the functionality of the overall system, unless you have no other option. Investigate the possibility of creating a component bid market, utilising local and possible geographically distributed teams, be they be in the Americas, Australia, India or China etc. Each component would be specified by a team and sent to the members of the bid market, you can decide the criteria for acceptance of a successful offer be it cost, time frame, consistent past record are a few items that come to mind. Competition never hurt any one and this approach then allows for change based on feedback from real world usage as the community uses the original components developed.
Just think of all the money that is not being spent by the original consulting organisation raising a plethora of Change Requests. Am hoping I've explained enough here to give you some ideas for reducing the costs associated with composite applications.
If you have some success stories, in this area, please leave a comment.
Tags applications composite scenario | Comments 0
