Dear Santa,
I ditched cable because I was fed up with paying for channels I never watched and for a year made good use of my Wii Console and NetFlix streaming service. But now the kids are tired of America's Funniest Home Videos and I miss watching Wimbledon on the BBC. So I've dived into the whole Internet TV thing and as I've been playing with it, I've decided what I would like for Christmas.
1) I would like the ability to subscribe to premium content directly with the content provider. None of this "who is your cable/satellite provider" nonsense. Example HBO Go. Dear Time Warner Cable, if I give you some money, please may I watch your stuff?
2) I would like receive content on any device or platform. Roku, AppleTV, iPad, Laptop...it doesn't matter. If it has an internet connection and a screen I should be able to use it to view the content I've just paid for. Example. Vudu doesn't want to play with Roku. Come on chaps, sort it out.
3) My location should not prevent me from viewing content. Example. I am British. I live in the USA and I would like to watch BBC Television. I would gladly pay the BBC license fee...if they would let me. The Roku devices sold in the UK can serve up BBC iPlayer, but the firmware on the Roku devices sold in the USA will not allow it. No fair! *pouts, stamps foot, installs Plex Media Server*
4) I would like to be able to set parental controls to restrict the content that my children have access to. Yes, I am a responsible parent. Yes, my children & I have had discussions about appropriate content. No, I am not always in the room with them when they're watching TV. Netflix offers parental controls and while greatly improved recently, they still pretty much suck. Amazon streaming video doesn't offer any parental controls and neither does Hulu. Don't even talk to me about Crackle. I just deleted that sucker from my Roku. Vudu seems to be the leader here, enabling parental controls to be set per device. What an excellent idea ;)
Come on people. We have the technology to make the consumer happy. Don't forget that the consumer also has the technology to circumvent much of this silliness. *cough, cough*virtual private network*cough, cough*BitTorrent*cough, cough*
Yours sincerely,
James
Wednesday, June 27, 2012
Friday, October 30, 2009
If the mainframe was an animal, which animal would it be?
I spent this week engaged in philosophical debate on the subject of mainframe application output management with a dozen hard core zSeries specialists from IBM. These chaps had spent their entire working lives in, on and around mainframe systems. Compared to these guys I felt like the new kid on the team because I had only been working in IT for twenty-ish years.
When I started work, mainframes were falling out of favor. They were big and expensive, and the trend was toward more, smaller mid-range systems. Distributed computing, if you will, over cheap, commodity hardware. When I started in systems integration we talked about building abstraction layers over legacy applications to make it easier to migrate their functions away from the mainframe. When virtualization become vogue I was struck by how the wheel had turned full circle. Now we wanted to consolidate all these smaller boxes into virtual machines on fewer, more powerful machines. Well hold on now, isn't a VM just a fancy name for an LPAR?
The more I work with mainframe systems, the more I am impressed about the thought that went into their design from the very beginning. I am also impressed with IBM's determination to keep the mainframe relevant. The mainframe, as it turns out, is an excellent platform for hosting guest O/S. I have been reading about Marist College running 600 virtual Linux systems on their z9. It seems that businesses that depend on mainframes today will continue to do so with confidence. However, I am not sure how many corporations who do not currently run a mainframe would consider installing one.
Now that the mainframe is back in favor, it became apparent that we're going to need people to support and maintain them. I am hearing stories that 20,000 graduates a year are being recruited and trained to tame the big iron. I can see the interface to and administration of mainframes changing dramatically over the next few years, because let's face it, it is a bit ugly right now. We young whiper-snappers from the distributed world know a thing or two about making user interfaces intuitive and easy to use. I also expect to see the proliferation of typically distributed development languages to the mainframe (and not just via unix system services or VMs). In the meantime, the principles of writing good code apply to all languages even if it does mean learning a bit of JCL, REXX, C & COBOL.
These days I think less in terms of distributed versus mainframe and more about blended solutions that benefit the business and end users. The mainframe is evolving from a T-Rex that'll tear your head off, into a big friendly dog that will dribble on you until you give it a hug.
James
Atlanta
October 2009
When I started work, mainframes were falling out of favor. They were big and expensive, and the trend was toward more, smaller mid-range systems. Distributed computing, if you will, over cheap, commodity hardware. When I started in systems integration we talked about building abstraction layers over legacy applications to make it easier to migrate their functions away from the mainframe. When virtualization become vogue I was struck by how the wheel had turned full circle. Now we wanted to consolidate all these smaller boxes into virtual machines on fewer, more powerful machines. Well hold on now, isn't a VM just a fancy name for an LPAR?
The more I work with mainframe systems, the more I am impressed about the thought that went into their design from the very beginning. I am also impressed with IBM's determination to keep the mainframe relevant. The mainframe, as it turns out, is an excellent platform for hosting guest O/S. I have been reading about Marist College running 600 virtual Linux systems on their z9. It seems that businesses that depend on mainframes today will continue to do so with confidence. However, I am not sure how many corporations who do not currently run a mainframe would consider installing one.
Now that the mainframe is back in favor, it became apparent that we're going to need people to support and maintain them. I am hearing stories that 20,000 graduates a year are being recruited and trained to tame the big iron. I can see the interface to and administration of mainframes changing dramatically over the next few years, because let's face it, it is a bit ugly right now. We young whiper-snappers from the distributed world know a thing or two about making user interfaces intuitive and easy to use. I also expect to see the proliferation of typically distributed development languages to the mainframe (and not just via unix system services or VMs). In the meantime, the principles of writing good code apply to all languages even if it does mean learning a bit of JCL, REXX, C & COBOL.
These days I think less in terms of distributed versus mainframe and more about blended solutions that benefit the business and end users. The mainframe is evolving from a T-Rex that'll tear your head off, into a big friendly dog that will dribble on you until you give it a hug.
James
Atlanta
October 2009
Thursday, April 02, 2009
Defining Project Scope
I am confused as to why some companies insist on running huge projects that invariably run into trouble with dates, quality and budget.
Here is an example of what I mean. I have worked for several customers who initiated the "SOA Project". These were multi-year, multi-team, multi-budget, multi-million dollar projects. And all of them ran into trouble one way or another just through being too big.
The last time I worked on one of these, my company was brought into to replace another vender who had thrown in the towel. i.e. It was so bad they would rather lose the account and walk away than complete the engagement.
SOA is not a project, it is an architecture pattern. Same thing applies to EDA. These are design principles that are applied to projects.
My thinking is this. A long term strategy should not be encapsulated as one project with a dozen phases. Instead, divide projects up into two categories:
Business Value projects are those that have a clearly defined goal with a concrete return-on-investment. These projects should be accounted for using a budget from a business unit. A couple of examples: Stream-line processes to reduce the average call handle time in a call center. Enable customer self service via the web.
Infrastructure projects involve bringing new technology into the enterprise that will increase the return-on-investment of Business Value projects. These projects should be classed as capital expenditure. For example: Implement a new middle-ware product to enable application integration with a legacy system. Implement an enterprise message system.
It may be that an infrastructure project becomes a pre-requisite for a specific business value project. If this is the case, then we should be clear on the cost accounting as this will dictate whether the infrastructure project is a good investment. For example, will this infrastructure enable other business value projects? Will it enable the IT team to better serve the business?
I look at these things as a Techie. Big problems are easier to solve if they are broken up into smaller problems. Small problems can be solved quickly (and for less cost) while working in the context of a long term strategy. We should maintain an agility that will enable us to change direction, as needed, without discarding that which has already been acheived.
In my view projects should not exceed six months in durarion. Three to four months would be the optimum size. In this way the business receives regular benefit from the IT team. Business propsers, makes more money, more money funds new projects, new projects help the business to prosper.
It boils down to this: Clearly defined goals based entirely on a well understood business value proposition. Small, agile teams working to a limited scope for rapid delivery.
James
Atlanta
April 2009
Here is an example of what I mean. I have worked for several customers who initiated the "SOA Project". These were multi-year, multi-team, multi-budget, multi-million dollar projects. And all of them ran into trouble one way or another just through being too big.
The last time I worked on one of these, my company was brought into to replace another vender who had thrown in the towel. i.e. It was so bad they would rather lose the account and walk away than complete the engagement.
SOA is not a project, it is an architecture pattern. Same thing applies to EDA. These are design principles that are applied to projects.
My thinking is this. A long term strategy should not be encapsulated as one project with a dozen phases. Instead, divide projects up into two categories:
Business Value projects are those that have a clearly defined goal with a concrete return-on-investment. These projects should be accounted for using a budget from a business unit. A couple of examples: Stream-line processes to reduce the average call handle time in a call center. Enable customer self service via the web.
Infrastructure projects involve bringing new technology into the enterprise that will increase the return-on-investment of Business Value projects. These projects should be classed as capital expenditure. For example: Implement a new middle-ware product to enable application integration with a legacy system. Implement an enterprise message system.
It may be that an infrastructure project becomes a pre-requisite for a specific business value project. If this is the case, then we should be clear on the cost accounting as this will dictate whether the infrastructure project is a good investment. For example, will this infrastructure enable other business value projects? Will it enable the IT team to better serve the business?
I look at these things as a Techie. Big problems are easier to solve if they are broken up into smaller problems. Small problems can be solved quickly (and for less cost) while working in the context of a long term strategy. We should maintain an agility that will enable us to change direction, as needed, without discarding that which has already been acheived.
In my view projects should not exceed six months in durarion. Three to four months would be the optimum size. In this way the business receives regular benefit from the IT team. Business propsers, makes more money, more money funds new projects, new projects help the business to prosper.
It boils down to this: Clearly defined goals based entirely on a well understood business value proposition. Small, agile teams working to a limited scope for rapid delivery.
James
Atlanta
April 2009
Friday, August 29, 2008
Shock Absorption for Legacy Systems
When it comes to performance testing, some people (not used to working with legacy systems) can have a hard time understanding that limiting the number of concurrent requests that hit the back end application can actually improve performance.
A very talented colleague of mine quite often refers to "the knee of the curve" i.e. the point at which response times dramatically increase because the target system is having a hard time of it.
In pre-sales calls we quite often describe our Legacy Integration products as the shock absorption layer for the back end application. We have a handy little feature that enables us to limit the number of concurrent requests active on a connector (a connector being the implementation of a specific protocol for a specific resource.e.g. TN5250, TN3270, JDBC and anything else you care to shake a stick at).
I spent this week tuning an implementation of our Legacay Integration product for a rather large client. The target was a test database on an underpowered iSeries. Past a certain point we saw dropped connections and all manner of strangness. I played around with our throttle control and the size of the connection pool. It didn't take long to find the sweet spot and the average response times dropped back to where they should be.
This is a good example of less is more :-)
To many of you reading this I am sure that the above seems like common sense. Any system, legacy or contemporary has a finite set of resources, so of course performance will degrade as the load exceeds the systems capabilites. My point is that shock absorption must be considered when planning and implenting an integration solution for Legacy systems.
For example, most iSeries shops run at or near capacity. When the iSeries Admins express concerns about the additional load that an integration solution may bring, the handy throttle control can save the day.
So, if your current legacy integration product does not cater for shock absoption or transaction throttling, feel free to drop me a line :-D
James
Atlanta
August 2008
A very talented colleague of mine quite often refers to "the knee of the curve" i.e. the point at which response times dramatically increase because the target system is having a hard time of it.
In pre-sales calls we quite often describe our Legacy Integration products as the shock absorption layer for the back end application. We have a handy little feature that enables us to limit the number of concurrent requests active on a connector (a connector being the implementation of a specific protocol for a specific resource.e.g. TN5250, TN3270, JDBC and anything else you care to shake a stick at).
I spent this week tuning an implementation of our Legacay Integration product for a rather large client. The target was a test database on an underpowered iSeries. Past a certain point we saw dropped connections and all manner of strangness. I played around with our throttle control and the size of the connection pool. It didn't take long to find the sweet spot and the average response times dropped back to where they should be.
This is a good example of less is more :-)
To many of you reading this I am sure that the above seems like common sense. Any system, legacy or contemporary has a finite set of resources, so of course performance will degrade as the load exceeds the systems capabilites. My point is that shock absorption must be considered when planning and implenting an integration solution for Legacy systems.
For example, most iSeries shops run at or near capacity. When the iSeries Admins express concerns about the additional load that an integration solution may bring, the handy throttle control can save the day.
So, if your current legacy integration product does not cater for shock absoption or transaction throttling, feel free to drop me a line :-D
James
Atlanta
August 2008
Monday, August 18, 2008
Palringo
I was looking for an IM Client for my wifes new iPhone 3g and came across Palringo. It is free and works realy well. It'll run on a bunch of platforms, so now I am using on my laptop to replace Windows Live Messenger and AIM.
I love finding those realy useful gadgets where it is apparent that the designers realy thought about it. I cannot beleive it is free. Considering some of the applications on iTunes that people want money for, I would have happily spent some cash on it.
I love finding those realy useful gadgets where it is apparent that the designers realy thought about it. I cannot beleive it is free. Considering some of the applications on iTunes that people want money for, I would have happily spent some cash on it.
Friday, June 20, 2008
Integration with Social Networks; What , Why & How
While debating this topic in the car yesterday with Chris on the way back from Charlotte, NC Chris, always the practical one, asked "Why do this, what is the point?". My immediate answer was "If some VP of Marketing wants to pay me to open up a new marketing channel then I'll take his money and implement a solution." Which I admit was pretty weak.
I am not too good at the vision thing. When some new concept is thrown out there I usually ignore all the noise until I see a solid application of it. Then I try to cut through the spin and the BS spouted by the wannabes trying to be part of the "next big thing" and find out what is it all about.
What is it? Why do it? How do I implement it?
So I decided to do a little more home work and come up with a better answer. One that would satisfy Chris.
The What
To enable any website to incorporate their own little mini social network among their own users and to have the capability of Identity Mapping to allow users to hook into the big Social Networks like Facebook and MySpace.
For example: When a user signs-in to your site, present a summary of their profile from Facebook. Query Facebook and MySpace to present your user with a list of their friends with upcoming birthdays and ask if they would like to send birthday e-cards, order a gift or send flowers.
The Why
It all comes down to getting the best return on investment out of the Marketing budget and helping your company to sell more product/services/widgets/stuff/dual-phase-inter-wobblers:
The main players in the Social Networking space are opening up by providing open source APIs. Facebook has aleady announced this.
Here is a quote from Bob Bickel
"We see the Facebook API and the Open Social API becoming the two standards for Social Application development over time – just like .Net and J2EE became the standards for web applications around the turn of the century. Ringside allows any website to build Facebook and/or Open Social applications today that will run on both your website as well as Facebook and the large Open Social websites like MySpace, hi5 and others."
Essentially Ringside is providing an abstraction layer to existing Social Network APIs. If you need to get going with implementing this kind of functionality for your company Ringside is saying "Start here".
Once you have your shiny socially aware website I think you will need to consider Business Intelligence tools to help you understand all that data you are collecting.
And you may also need to integrate with your internal systems to further enhance your site's capabilities. For example, customer self service functions that enable your users to tell you about changes of address, telephone number and other data private held by you on behalf of your customer.
James
Atlanta
June 2008
I am not too good at the vision thing. When some new concept is thrown out there I usually ignore all the noise until I see a solid application of it. Then I try to cut through the spin and the BS spouted by the wannabes trying to be part of the "next big thing" and find out what is it all about.
What is it? Why do it? How do I implement it?
So I decided to do a little more home work and come up with a better answer. One that would satisfy Chris.
The What
To enable any website to incorporate their own little mini social network among their own users and to have the capability of Identity Mapping to allow users to hook into the big Social Networks like Facebook and MySpace.
For example: When a user signs-in to your site, present a summary of their profile from Facebook. Query Facebook and MySpace to present your user with a list of their friends with upcoming birthdays and ask if they would like to send birthday e-cards, order a gift or send flowers.
The Why
It all comes down to getting the best return on investment out of the Marketing budget and helping your company to sell more product/services/widgets/stuff/dual-phase-inter-wobblers:
- Learn more about your consumer to design better campaigns
- Get feedback as to how your brand is faring or how a campaign is operating
- Find new ways to sell your product or service; create special offers for each individual much like Amazon does.
The main players in the Social Networking space are opening up by providing open source APIs. Facebook has aleady announced this.
Here is a quote from Bob Bickel
"We see the Facebook API and the Open Social API becoming the two standards for Social Application development over time – just like .Net and J2EE became the standards for web applications around the turn of the century. Ringside allows any website to build Facebook and/or Open Social applications today that will run on both your website as well as Facebook and the large Open Social websites like MySpace, hi5 and others."
Essentially Ringside is providing an abstraction layer to existing Social Network APIs. If you need to get going with implementing this kind of functionality for your company Ringside is saying "Start here".
Once you have your shiny socially aware website I think you will need to consider Business Intelligence tools to help you understand all that data you are collecting.
And you may also need to integrate with your internal systems to further enhance your site's capabilities. For example, customer self service functions that enable your users to tell you about changes of address, telephone number and other data private held by you on behalf of your customer.
James
Atlanta
June 2008
Thursday, June 19, 2008
Application Integration with Social Networks
A former colleague of mine called yesterday to talk about a new idea being proposed by Ringside Networks.
These guys were the power behind Bluestone and JBOSS. My friend's thinking is that these chaps are two for two and if they think this is a good thing to invest in then it is worth a close look.
It certainly is a cool idea. They have come up with an application engine, the Ringside Social Application Server, that is designed to add a social context to a web application. The idea is to make your web site more of a community thing. So, for example (taken from Ringside's web site), if you sold running shoes then you could provide functions for your sites users to organize and take part in events or find a training partners of similar skill & experience in the same area.
It strikes me as a new concept in sales & marketing. Social networking sites represent a new way to reach a large group of people who are actually interested in your products or services and will come to you.
Ringside estimate that there are 67 million users of social network sites and that advertising from search engines can only take you so far. They propose that the smart companies will leverage social networking for more targeted marketing. They also estimate that there are approximately 19,000 applications leveraging the Facebook API alone.
The key fact about this new push for an open source social networks application server that strikes a chord with me is that the idea came from a real, business driven need. The original authors were paid to create a social context for the running shoe company described in the example above. They then set about creating a more generic engine that could be quickly implemented for anyone else.
What would turn me off would be to hear that someone dreamed it up and decided to make it. I am not a fan of "build it and they will come". I much prefer to see that an idea has real business value. The fact that someone has already been paying for services to implement this idea tells me that it does.
The next thing to discover is whether or not there is value in integrating these applications with back end systems be they legacy or contemporary. With our ability to expose legacy business functions as services, for example as web services, and a range of options for communications (HTTPS, JMS, etc) it should be easy to integrate with the Ringside Social Networks Application Server.
James
Charlotte, NC
June 2008
These guys were the power behind Bluestone and JBOSS. My friend's thinking is that these chaps are two for two and if they think this is a good thing to invest in then it is worth a close look.
It certainly is a cool idea. They have come up with an application engine, the Ringside Social Application Server, that is designed to add a social context to a web application. The idea is to make your web site more of a community thing. So, for example (taken from Ringside's web site), if you sold running shoes then you could provide functions for your sites users to organize and take part in events or find a training partners of similar skill & experience in the same area.
It strikes me as a new concept in sales & marketing. Social networking sites represent a new way to reach a large group of people who are actually interested in your products or services and will come to you.
Ringside estimate that there are 67 million users of social network sites and that advertising from search engines can only take you so far. They propose that the smart companies will leverage social networking for more targeted marketing. They also estimate that there are approximately 19,000 applications leveraging the Facebook API alone.
The key fact about this new push for an open source social networks application server that strikes a chord with me is that the idea came from a real, business driven need. The original authors were paid to create a social context for the running shoe company described in the example above. They then set about creating a more generic engine that could be quickly implemented for anyone else.
What would turn me off would be to hear that someone dreamed it up and decided to make it. I am not a fan of "build it and they will come". I much prefer to see that an idea has real business value. The fact that someone has already been paying for services to implement this idea tells me that it does.
The next thing to discover is whether or not there is value in integrating these applications with back end systems be they legacy or contemporary. With our ability to expose legacy business functions as services, for example as web services, and a range of options for communications (HTTPS, JMS, etc) it should be easy to integrate with the Ringside Social Networks Application Server.
James
Charlotte, NC
June 2008
Subscribe to:
Posts (Atom)