Software Development - From Inside the Cubicle
Obviously "mobile" is a hot topic today. It amazes me to see everyone with a smart phone. I don't think anyone can argue the value that device provides in your hands as you go about your day. Just being able to find your destination on map is of value to those "directionally challenged." In corporate America, it is also obvious that each and every employee of company X has their own smart phone. And more and more technology-savvy employees want to conduct business using these devices. This presents an interesting challenge to corporate America. How can they enable their employees to conduct some aspects of their business using the phones that they already have.
So based on my history with IT shops, here is the typical thinking. The CTO says that they need to provide a mobile presence to their sales managers, let say. "Let's create a mobile application that gives access to their customer information database", for example. Sounds like a great idea. But because this is a new cutting edge project, the effort is done as a skunkworks project, off to the side outside the boundaries of normal IT tools and processes. A group of sharp (and typically young) developers are given free reign to create this app. They go off and so some great work, producing a simple but usable application.
This scenario poses lots of problems. Obviously in the BYOD (bring your own device) world, we are have numerous platforms that must be supported to keep everyone happy. We also have a security issue. Access to the corporate network requires some type of VPN and we are now exposing corporate information to a non-corporate device. I would assume this causes lots of lost sleep.
But in my world, there is also a more fundamental issue. Developing key applications for corporate employees outside of the normal IT controls is not a good practice to follow. Managing requirements, properly testing, and controlling the release process are all necessary aspects to mobile app development. There are definitely differences in expectations of mobile app users in the frequency of releases and bug fixes. But these can be addressed without the exclusion of best practices.
The IBM Mobile Development Lifecycle Solution (IMDLS) product offering was created to help solve this problem. By combining the IBM Worklight solution with the IBM Rational Application Lifecycle solution, the IMDLS brings control and management to your mobile application development efforts. IBM Worklight also provides a first class development environment with tools to allow you to create-once, deploy-everywhere to support the multiple mobile platforms that are out there.
In a previous life, I talked my boss into buying one copy of Rational Rose, the premier UML modeling tool of the day. It was I believe version two and it was on some UNIX platform. For those that remember these days, Rose on UNIX didn't work very well (lots of crashes). I then went on to join Rational software and I believe I got the job partly because I had Rose on my resume. My first two years with Rational were all about promoting and selling Object-oriented Analysis & Design classes and Rational Rose. And we sold a lot of them. Most enterprises those days had a few leaders that kept abreast of the trends and OO was a hot topic. And Rose was considered a necessary part of the solution. You needed a tool that could capture the UML diagrams that were going to revolutionize the software architecture profession.
Well, it didn't quite work out that way. I am still today a strong proponent of modeling and believe that any good architect needs to have strong modeling skills to be able to communicate their architectural ideas. I am sorry but Powerpoint and/or Visio just don't cut it. That being said, it is apparent to me that in general, software IT shops do not consider models to be a key and strategic piece of their software development lifecycle!!! I have to wonder why.
One place to look is the actual perception of UML. No doubt that UML has traveled a rocky road. It started out with such high expectations and maybe that is where the problems began. I think there was a a "silver bullet" feeling that it never was intended to live up to. Various revisions seemed to complicate things instead of clarify them. As MDD/MDA/PBE took off and began to show promise, UML was again criticized for not being "right" as the specification for driving out detailed abstractions. I think Bertrand Meyer captured an early feeling about UML in his 1997 satirical article. To some UML had completely missed its mark.
Another perspective is that UML is not understood by or even relevant to others in the software development lifecycle. OK, use cases should be understood by your requirements people, but you hardly need to know UML to understand a stick figure and oval use case diagram. So much of how a developer creates code these days is about following standard patterns which don't have to be specified by an architect. Testers for the most part aren't helped that much by a model. And UML has probably failed the operations people the most with its almost laughable deployment modeling capabilities (see Rational Software Architect's robust topology modeling capabilities to see what it takes).
This doesn't however alter my belief that modeling needs to be a key component in software architecture, for maybe nothing more than drawing pictures (I know it sounds like Visio). However, the underlying model behind the picture still provides value, particularly if you are in an industry with strong industry model influences ( i.e. CIM for the E&U industry, TMForum models for Telecommunications). It is important that architectural constructs are based on what the industry says is important.
So I continue to preach modeling and I use Rational Software Architect almost every day. I know there are those architects out there that rely on a UML modeling tool to communicate their architectural know how. It's too bad there aren't more of us out there.
I have two daughters, 14 and 10 years old. For the past few years I have wondered if either of them has any interest in the software world. I remember as a kid I made a bold statement to my dad (who was in the IT field also) that I wanted nothing to do with the software business. Look at me now. Besides, both my wife and I have computer-related degrees, so there must be some genes in those two girls that would make them a natural, right?
I found early on in college that the logic of a software program made perfect sense to me. There was one and only one right answer (unlike the English classes I had to take) and the software did exactly what you told it to do. It resonated with me. However, in today's "short attention span" digital world that my kids are growing up in, the concept of learning to program using today's development environments and books doesn't look appealing even to me. In my early days of exploring what code can do, the challenge of learning the syntax and achieving successful compilations was the major challenge. Learning a programming language from a book was not the best way to learn and it took lots of trial and error. The compiler got a workout.
So I started looking around (i.e. Google) for some creative solutions. I landed on the Alice project which was even more intriguing after learning Randy Pausch was one of the creators (if you haven't watched his last lecture, it is well worth it). Alice provides a 3D programming environment that allows you to create and manipulate a 3D scenario using programming techniques. You create objects and make them move and control the scene all via programming techniques. It takes advantage of today's video craze; they can create their own movie! Being an Eclipse person today, I eagerly awaited an Eclipse version of Alice. As Alice is driven by the university community, the release cycle was very long and frankly I grew impatient. I have yet to install it and even try it. I wish the project well, but haven't had the energy to try it out.
Within the last year or two, I became aware of the Khan Academy. I found myself watching some of the Calculus lessons and getting my college Calc book out (geek). I just discovered that they now have a computer science category. Very cool. I checked it out. I was really expecting to see some whiteboard-type lectures on programming fundamentals; for loops, variables, functions, etc. Well to my surprise they took a very different approach. They use an online environment to learn to program. The code is right there in a text box. You can change it and run it and immediately see your results. A video gives you the basics and you can then play to your heart's content. I spent about a half an hour playing with their Pascal's Triangle program. Very very cool. I was impressed. Khan Academy gives credit for inspiring this type of learning to Bret Victor. He has thought a lot about how to learn programming and it makes a ton of sense. You can read all about his ideas here. Again, well worth the read.
As an IBMer, this obviously brings me to the type of development environments we provide. I am an avid Rational Application Developer and Rational Software Architect user. These products really represent the other end of the spectrum when it comes to development environments, and rightly so. Enterprise level software development environments are not catering to those learning the program language. Go out and learn java first before you build your first EJB-based web service. However, I do believe there are some lessons that can be learned from these new learning techniques. One area that resonates with me is UML modeling. For my first two years at Rational Software, I taught an Object-oriented Analysis & Design class once a month. This was back in the good old days where OOA&D and modeling were relatively new to the masses. Most organizations had "the guy" that was dabbling in this space and convinced someone to bring Rational in to teach a larger group. Rational Software Architect is a great UML modeling tool and I have had much success with it. But I believe that to this day, in order to learn to be a successful architect using UML, you are stuck with grabbing a fully featured modeling tool and a book and slugging through it. There is no way that I know of (please let me know) to grasp the concepts of UML in a way like Bret Victor's vision for learning to program. I am not sure what that looks like in my head, but someone way smarter than me I am sure can think of something.
I am going to show the Kahn Academy computer science lessons to my 10 year-old first. She is the creative one. Hopefully I can trigger her interest in programming that I know is in her DNA, unless it has skipped a generation.
DarrellSchrag 120000MK4C 1,073 Views
HTML5 versus native? Everyone has to look at this question and constantly re-evaluate your answer. The focus of your mobile application has a lot to do with it.
LinkedIn is a great example of how quickly things change. Last May (less than 12 months ago), LinkedIn was touting its iPad app as 95% HTML5 with only its main screen being native. Relying heavily on Node.js, they made the comment that "if the performance wasn't there, we wouldn't have gone with the web." What has changed since then?
Was it speed? No. In their most recent version, they indicated that it was based on the fact that users were spending more time in the app and it was running out of memory. Interesting! They also wanted to take advantage of the "smoothness" of some of the native widget animations.
Another disadvantage they pointed out was tooling support. Reliable debuggers and performance monitors to name a few.
It looks like the tooling vendors need to step up and help the HMTL5 effort. I will be watching closely to see what IBM has to offer here.
If you would like to discuss this or more on the topic of mobile development, be sure to attend the IBM Rational Innovate Conference this June.
See you there!
Back in my early programming days, every team had their "script guy" (or gal). There was always the need to automate some task, whether it was backups to tape or a cron job to check for a new file to FTP. The sys-admin community was always the go-to group that had long ago figured out that a good script was worth its weight in gold. I was fortunate to work for a DoD-aerospace company on a secret project right out of college. The amount of process and governance that we were under was tremendous now that I look back (I thought it was normal back then, yea right). We created a truly continuous delivery environment, albeit some of the steps were manual. Each night, all of the change sets for all of the finished change requests were examined. Each file that was changed was checked to insure that there were no other changes that it depended on that were not on the completed change request list. Using VAX logicals, we were able to have code at different deployment levels (DEV, INT, QA, STAGING, PROD) and use the same build mechanism.
Fast forward 25 years. The challenges and demands for DevOps are the same, yet the size and breadth of "common" everyday IT applications today is comparable to the Air Force project I was on 25 years ago. And if you look at the current DevOps solutions out there today, you see the same script guy mentality all balled up in the open source solutions and niche players being increasingly utilized. Hudson, Jenkins, Chef, Puppet, etc. are all the result of a group of smart "script guys" that needed a way to get something done without having to stay late or come in on weekends.
DevOps is a very big and wide buzz word today getting lots of traction. And like other groundswells, it got its start as a grassroots effort by "script guys." But some new factors have caused DevOps to be embraced by enterprise companies like IBM. Cloud computing is a dream come true for the DevOps community. To not only be able to continuously build and deploy but also provision without the 6 month lead time to procure hardware, we now have a much more flexible and dynamic environment to answer the more than often asked question. "Can we quickly stand up an environment to fix <insert problem here>?" Without a cloud solution, this often meant out-prioritizing other efforts to steal their hardware.
The IBM SmartCloud Continuous Delivery solution encompasses all of these good things in one product. Out of the box is the SmartCloud Provisioning solution as well as Rational Team Concert for a nice and robust build engine. If you want to plug in your open source solution like Jenkins or Hudson, feel free. You can also take advantage of IBM Rational Build Forge and Rational Automation Framework if you choose. Want to use IBM Workload Deployer or IBM Pure Systems, be my guest.
But don't look now. A quick search on Google shows a slew of open source cloud solutions. Stay tuned for more DevOps fun.
I had a long conversation with a colleague the other day concerning the state of software architecture. I asked the question "are software systems these days architected?" The reason for asking is that it appears to me that more and more of the challenges that faced architects (throughput, concurrent users, security, etc.) have been tackled by features of the platforms and components that we build software systems upon. Don't get me wrong, there are still some software systems that suffer from some really bad architecture decisions, but some of the examples if have seen are decisions any good developer should have flagged.
Take your average IBM WebSphere shop. It is my assertion that it is fairly easy to find developers that have written software for some fairly complex systems on top of the IBM WebSphere middleware stack. And I would also assume that there are some fairly well established best practices that by now are mainstream and common knowledge. (For the record, I am not one with this type of experience, so I am speculating here).
So how much architecture is necessary these days when it comes to building a transactional web application on WebSphere app server? I would say that the understanding the different flavors and deployment options you have with WebSphere is the architecture skill that is necessary. Understanding the non-functional requirements of a proposed system and choosing the right middleware/hardware deployment is the needed skill? IBM offers server sizing for all types of situations. Is there a need for an architect here?
If you move down a level of abstraction, creating the correct EJBs can sometimes be tricky and I would assume you could make some bad decisions here. But I would also expect a developer seasoned in creating EJBs would be able to navigate this area and make good decisions. Again, is architecture needed here?
Jason Bloomberg wrote a blog entry last year. His assertion was that no one is doing enterprise architecture because most enterprise architectures are created after-the-fact. You wouldn't hire an architect after a bridge was built to document its architecture, but most enterprise architectures are created this way. Granted the goal is to ultimate create a to-be architecture and steps to get there, but the initial architecture was not architected, it was grown.
What is the state of any of the architecture professions these days? How has it evolved?