The 2009 edition of the celebrated Arcati Mainframe Yearbook is now available to view or download (free of charge) from www.arcati.com/newyearbook09.
It includes a mainframe strategy section with a selection of articles by industry gurus and vendors on topics such as: IBM z/OS VWLC software pricing optimization; The credit crunch: the impact on System z (aka mainframes); and Staying on top of Enterprise Extender.
For many people the highlight each year is the mainframe user survey. This illustrates just what's been happening at users’ sites. It’s a good way for mainframers to compare what they are planning to do with what other sites have done. I will be looking at some of the survey highlights next week.
The full vendor directory section gives contact details and other useful information in a summary format for all major vendors, consultants, and service providers in the z/OS environment.
There’s also a media guide for IBM mainframers. This lists information resources, publications, and user groups for the z/OS environment.
Next comes the glossary of terminology, which contains a large number of definitions of mainly mainframe-related terms.
The final section contains technical information – z10 model tables; mainframe hardware timeline 1952-2009; and mainframe operating system development.
In order for the Yearbook to be free, it is supported by sponsors and advertisers. This year's sponsors were Software Diversified Services (SDS), Value-4IT Ltd, and zCOST Management.
To see this year's Arcati Mainframe Yearbook, click on http://www.arcati.com/newyearbook09.
Now that the Yearbook is complete... if anyone needs a good technical writer etc, please contact me at trevor@itech-ed.com.
Monday, 26 January 2009
Monday, 19 January 2009
The quick and the dead
I thought this week I would talk a little bit about Agile software development. If you’ve not come across it before, and I’m sure you probably have, it refers to a number of similar methodologies for software development, for example Scrum. Why is it worth talking about? Well the answer is to do with the way anything developed can be rapidly updated in a controlled way making the best use of teamwork.
Basically, Agile software development is a way of managing a project that involves numerous small improvements to a piece of software rather than starting with a massive long-term plan and working towards it. It’s sort of like the ant approach to solving a problem. Lots of little actions take place by a number of different individuals and at the end of the project some massive piece of software has been created (or in the ants’ case, a massive ant hill!).
Each of these small iterations is worked on by a team, and they work their way through the standard software development life-cycle. The time for these iterations is usually between a week and a month. So each increment goes through planning, requirement analysis, design, coding, unit testing, and acceptance testing phases.
The technique is quite popular with programmers because there is usually little emphasis on written documentation, although there is face-to-face communication, and the team, which is usually between five and ten people, typically contains a customer representative. In fact that person is usually the one creating any written documentation.
At the end of each iteration, customers and stakeholders will review the progress so far and can then re-evaluate priorities. So this is why the technique is described as agile. The original plan is not written in stone and new choices can be made at any time during the project to ensure that customers maximize their return on investment.
Team members usually get to know each other quite well and know what each one is working on. Regular meetings of the whole team can help to identify any problems and the team as a whole can work on solving them. Meetings are held with everyone standing up – which focuses the mind and stops meetings dragging on for long periods of time.
Agile software development originated in the 1990s. The Agile Alliance (www.agilealliance.org) was formed by a number of organizations in the early 2000s to promote Agile software development. Agile methodologies like to see themselves as being adaptive, and they contrast that to other methodologies that are predictive. Typically, engineering methods tend to try to plan out a large part of the software process in great detail over a long span of time. The problem with this approach is that things may change between the plan being originally devised and the software being finally delivered. This means that they try to resist change. The advantage that agile methodologies offer is that they embrace change. They can adapt to changes and include them in the final software.
A second difference is that Agile methodologies are people-oriented rather than process-oriented. This means that the final process will be one that is usable by people rather needing people to learn to use the process.
So Agile software development is designed for scope creep – mission creep – that process whereby something was created for one purpose and then (while it’s there!) has other things required of it.
So why call the article the ‘quick and the dead’? I was metaphorically suggesting that Agile computing is quick (and very much alive) and older monolithic strategies might be dead in the water. What do you think?
Basically, Agile software development is a way of managing a project that involves numerous small improvements to a piece of software rather than starting with a massive long-term plan and working towards it. It’s sort of like the ant approach to solving a problem. Lots of little actions take place by a number of different individuals and at the end of the project some massive piece of software has been created (or in the ants’ case, a massive ant hill!).
Each of these small iterations is worked on by a team, and they work their way through the standard software development life-cycle. The time for these iterations is usually between a week and a month. So each increment goes through planning, requirement analysis, design, coding, unit testing, and acceptance testing phases.
The technique is quite popular with programmers because there is usually little emphasis on written documentation, although there is face-to-face communication, and the team, which is usually between five and ten people, typically contains a customer representative. In fact that person is usually the one creating any written documentation.
At the end of each iteration, customers and stakeholders will review the progress so far and can then re-evaluate priorities. So this is why the technique is described as agile. The original plan is not written in stone and new choices can be made at any time during the project to ensure that customers maximize their return on investment.
Team members usually get to know each other quite well and know what each one is working on. Regular meetings of the whole team can help to identify any problems and the team as a whole can work on solving them. Meetings are held with everyone standing up – which focuses the mind and stops meetings dragging on for long periods of time.
Agile software development originated in the 1990s. The Agile Alliance (www.agilealliance.org) was formed by a number of organizations in the early 2000s to promote Agile software development. Agile methodologies like to see themselves as being adaptive, and they contrast that to other methodologies that are predictive. Typically, engineering methods tend to try to plan out a large part of the software process in great detail over a long span of time. The problem with this approach is that things may change between the plan being originally devised and the software being finally delivered. This means that they try to resist change. The advantage that agile methodologies offer is that they embrace change. They can adapt to changes and include them in the final software.
A second difference is that Agile methodologies are people-oriented rather than process-oriented. This means that the final process will be one that is usable by people rather needing people to learn to use the process.
So Agile software development is designed for scope creep – mission creep – that process whereby something was created for one purpose and then (while it’s there!) has other things required of it.
So why call the article the ‘quick and the dead’? I was metaphorically suggesting that Agile computing is quick (and very much alive) and older monolithic strategies might be dead in the water. What do you think?
Monday, 12 January 2009
CICS Explorer
IBM introduced a SupportPac containing the new CICS Explorer Eclipse-based graphical tooling interface for CICS on the 5 November 2008. But what is it?
Basically, it’s a new Eclipse-based systems management environment for application programmers, system programmers, and other operational staff. The idea behind it, I guess from IBM’s point of view, is to provide a modern interface to CICS, which, as you know, as been around since 1969, and is currently at Version 3.2 (although second time around because it reached Version 6 then started again!).
CICS Explorer is highly-customizable, and can be used to integrate information from CICS and third-party tools, which means that users need have only one Master Terminal for all their software. IBM has made using it easier for beginners because it comes with integrated help, tutorials, and a direct connection to the CICS Information Center.
The IBM site at http://www-01.ibm.com/software/htp/cics/explorer/features/ lists its features including:
Why are modern and easy-to-use such important features? Well it goes back to my blog the other week about the ageing mainframe work force. This particular tool helps to fix the ageing-workforce problem in two ways.
Firstly, you can replace experienced and skilled mature staff with less-experienced and skilled staff, because it’s easy for them to access help from CICS Explorer. So there’s no need to replace retiring experts with younger experts, you just need to replace them with standard IT people.
The second thing is that staff who are familiar with Java can make use of Explorer’s Eclipse interface, and before they know it, they are experts at CICS! And Eclipse-based plug-ins can be integrated in CICS. The old and the new combined, making working with CICS sound youthful and dynamic and appealing to the younger Java programmers.
And because it can run in a browser, it can be run from anywhere. I’m currently picturing a die-hard CICS programmer from 20 years ago, fixing a problem using the browser on his phone, while attending a family party. Work-life balance and all that!
Definitely a product we’re going to hear more of in 2009.
Basically, it’s a new Eclipse-based systems management environment for application programmers, system programmers, and other operational staff. The idea behind it, I guess from IBM’s point of view, is to provide a modern interface to CICS, which, as you know, as been around since 1969, and is currently at Version 3.2 (although second time around because it reached Version 6 then started again!).
CICS Explorer is highly-customizable, and can be used to integrate information from CICS and third-party tools, which means that users need have only one Master Terminal for all their software. IBM has made using it easier for beginners because it comes with integrated help, tutorials, and a direct connection to the CICS Information Center.
The IBM site at http://www-01.ibm.com/software/htp/cics/explorer/features/ lists its features including:
- Manage secure connections to CICS runtime and CICS Tools from a single panel.
- Wide range of standard queries plus rich query editor so you can easily modify these or create your own.
- Much easier to follow a sequence of resource relationships.
- Data filtering helps to reduce the volume of data displayed.
- CICS Explorer can run in a browser.
- Etc.
Why are modern and easy-to-use such important features? Well it goes back to my blog the other week about the ageing mainframe work force. This particular tool helps to fix the ageing-workforce problem in two ways.
Firstly, you can replace experienced and skilled mature staff with less-experienced and skilled staff, because it’s easy for them to access help from CICS Explorer. So there’s no need to replace retiring experts with younger experts, you just need to replace them with standard IT people.
The second thing is that staff who are familiar with Java can make use of Explorer’s Eclipse interface, and before they know it, they are experts at CICS! And Eclipse-based plug-ins can be integrated in CICS. The old and the new combined, making working with CICS sound youthful and dynamic and appealing to the younger Java programmers.
And because it can run in a browser, it can be run from anywhere. I’m currently picturing a die-hard CICS programmer from 20 years ago, fixing a problem using the browser on his phone, while attending a family party. Work-life balance and all that!
Definitely a product we’re going to hear more of in 2009.
Monday, 5 January 2009
Enterprise WOA
I talked about mash-ups and the enterprise a couple of weeks ago. This time I’d like to take a look at WOA and how that fits into the enterprise.
So, like a good philosophy essay, let’s start with some definitions. What is WOA, or perhaps more simply, what do the letters of the acronym stand for. WOA stands for Web-Oriented Architecture. It’s a way of building large-scale Web services. It’s like SOA on steroids! Gartner have a sort of definition. They think of it as SOA plus WWW plus REST. And just to unpick that definition a little, it’s Service-Oriented Architecture (the one that we’ve all been hearing about for the past five years) plus the World-Wide Web plus REpresentational State Transfer.
SOA, as you’re probably well aware, is a software design that breaks down a problem into modular, distributable, shareable, and loosely-coupled components. The World-Wide Web part refers to Web-related technologies such as HTTP(S) (HyperText Transfer Protocol Secure), (X)HTML (eXtensible Hypertext Mark-up Language), RSS (Really Simple Syndication), Atom Publishing Protocol, RDF (Resource Description Framework), and others.
With REST, there are no objects or methods, rather, everything is a resource. In a RESTful system, an agent communicates with a resource using its location, a verb describing the operation, and a representation of the desired state.
SOA usually comes associated with SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language). Now the problem many people experience is that the WSDL specification can be difficult to understand, domain specific, and difficult to extend or adapt. In addition, SOAP messages can be complex and difficult to understand without some knowledge of the services involved.
The advantage of WOA is that it uses existing technologies. A WOA interface can be used from any Web-enabled programming language. WOA can be easily extended.
But, I hear you say, can I use this with my mainframe? The answer is yes. And the reason is that WOA is ready for this kind of usage. It is simple, scalable, and extensible. It makes use of all the benefits of HTTP – such as using PUT, GET, POST, and DELETE requests. And it promotes the use of semantically rich representations.
You may remember me saying that mainframe mash-ups can use REST. The use of REST is probably the big difference at the moment between traditional SOA and WOA – although, every diagram shows WOA as being a subset of SOA. And it’s not all good news about REST, there are certain areas where it’s not great – such as two-phase commit, messaging, and asynchronicity.
But having said that, the use of REST and SOA puts the focus on Web resources rather than services and it just might be the way to get SOA projects to a satisfactory conclusion.
So, like a good philosophy essay, let’s start with some definitions. What is WOA, or perhaps more simply, what do the letters of the acronym stand for. WOA stands for Web-Oriented Architecture. It’s a way of building large-scale Web services. It’s like SOA on steroids! Gartner have a sort of definition. They think of it as SOA plus WWW plus REST. And just to unpick that definition a little, it’s Service-Oriented Architecture (the one that we’ve all been hearing about for the past five years) plus the World-Wide Web plus REpresentational State Transfer.
SOA, as you’re probably well aware, is a software design that breaks down a problem into modular, distributable, shareable, and loosely-coupled components. The World-Wide Web part refers to Web-related technologies such as HTTP(S) (HyperText Transfer Protocol Secure), (X)HTML (eXtensible Hypertext Mark-up Language), RSS (Really Simple Syndication), Atom Publishing Protocol, RDF (Resource Description Framework), and others.
With REST, there are no objects or methods, rather, everything is a resource. In a RESTful system, an agent communicates with a resource using its location, a verb describing the operation, and a representation of the desired state.
SOA usually comes associated with SOAP (Simple Object Access Protocol) and WSDL (Web Services Description Language). Now the problem many people experience is that the WSDL specification can be difficult to understand, domain specific, and difficult to extend or adapt. In addition, SOAP messages can be complex and difficult to understand without some knowledge of the services involved.
The advantage of WOA is that it uses existing technologies. A WOA interface can be used from any Web-enabled programming language. WOA can be easily extended.
But, I hear you say, can I use this with my mainframe? The answer is yes. And the reason is that WOA is ready for this kind of usage. It is simple, scalable, and extensible. It makes use of all the benefits of HTTP – such as using PUT, GET, POST, and DELETE requests. And it promotes the use of semantically rich representations.
You may remember me saying that mainframe mash-ups can use REST. The use of REST is probably the big difference at the moment between traditional SOA and WOA – although, every diagram shows WOA as being a subset of SOA. And it’s not all good news about REST, there are certain areas where it’s not great – such as two-phase commit, messaging, and asynchronicity.
But having said that, the use of REST and SOA puts the focus on Web resources rather than services and it just might be the way to get SOA projects to a satisfactory conclusion.
Subscribe to:
Posts (Atom)