Category Archives: Enterprise

3 Trends about to take off – Part 1

alexa-small2017 is halfway over and while some of these trends started a few yeas ago I think we’re about to see a few of these really catch-on, and by catch-on, I mean go mainstream and get funded.

Over the next week I’m going to discuss these three trends in a little more details and provide some code or projects to help you get started!

Trend 1 - Alexa / Voice / AI Chat

What does user experience look like without a mouse & keyboard or easy to enter form fields? How do people talk to AI systems to solve problems? These systems can be through devices like Alexa or virtual systems like automated chatbots. Understanding psychology and human behavior become just as valuable as business knowledge when designing these systems. Because of this we will see new software architectures come into play that deal with these variations and have multiple and guided user flows.

Trend 2 – JS/UI Architecture

SPAs (Single Page Applications) built on frameworks like Angular and React changed the way we think about building software. But for the longest time it was code, code, code without much thought of how it’s going to scale, and how it’s going to be supported in the enterprise. These systems need to hang around and be maintainable for 10 years, refactoring your apps should not have to entail complete system rewrites. Having architectures for UIs that allow for modular building and refactoring are crucial for adoption of these technologies that change every 9 months.

Trend 3 – Augmented Reality

There’s more and more data about the world around us. Why not provide more ways for people to interact with this data? Why make everyone have to look something up on a browser or an app? Voice combined with computer vision begins to bridge this gap. Google Glass still might not be the right use case, but camera augmentation, heads-up displays in cars, smart kiosk and push voice will be where this begins to have application.

The software/website bloat cycle.

  1. Someone or some company creates useful software.
  2. Features get added to make useful software profitable or make more users happy.
  3. Features don’t get removed because they make some customers happy and you don’t have time/money to test removal.
  4. Over time the software gets so complicated, you forget all the features.
  5. In the quest for perfection/complete testing, you find that you can’t be perfect or complete and settle for less than 100% test coverage.
  6. Some feature breaks because it wasn’t tested.
  7. There’s a bug fix/patch to get this fixed ASAP.
  8. Software get’s duct tape or worse people loose their job because it broke.
  9. Management decides they need to convert to a new system or completely rebuild the old system because it’s too complicated and creates errors.
  10. Go to 1

Now this cycle will repeat, always, no matter how much time and effort you spend keeping the code clean or testing, inevitably entropy will catch up with your software or your website. The only advise is that if you find yourself in steps 5-8 of the bloat cycle, get a new job, or get to step 9 as soon as possible.

Arch Villains – FUD Man & Frameworkinstein

I was reading this article over at 37signals and I realized that my enemy is inefficiency and it takes form in two arch villains:
  • FUD Man – This is the person on the team or the architect that creates enough Fear Uncertainty and Doubt to ensure a solution/application is over-engineered and over-budgeted. This usually takes the form of a J2EE solution requiring offshore to get it done on time and on budget.
  • Frameworkinstein – This person is usually FUD Man disguised as a hero coming in to propose a framework to take away time but in actuality it adds time and complexity to an already over-engineered solution.

How do you defeat these two in corporate IT? Ruby? Dynamic Languages? No. Those are usually the wrong weapons and you can’t fight FUD with something people know little about. To win this war you need to take lessons from Sun Tsu. Here’s some tactics:

  1. Attack The Foundations of FUD by finding the most important emotional driver for the decision maker. If it’s cost make it cheaper, if it’s quality, introduce a quality process, if it’s power, caste doubt on his/her ability to control the project.
  2. Ask questions like: How would we do this if we had half the time and budget to management without FUD Man around to respond.
  3. Find a better framework than proposed only to show that one is not really needed.
  4. Show examples of how someone smarter than you or your villain would do something different and how they succeeded.
  5. Create a prototype/example in a few hours that does a good majority of the work, and ask management: If this only took me a few hours, how can we spend all this time and effort on something that’s essentially the same thing?

Good Luck in your fight, may the force be with you!!!

Preventing Software Rot – Part 1

In my years of working with large systems and complicated architectures I have found the following to be true:

  • any system architecture will eventually become out dated
  • programmers will continue to extend a system beyond it’s architecture
  • the system will eventually end up in disarray because it is held together with rubber bands and duct tape
  • management will scrap the system because it’s too costly to maintain
  • system will be replaced by new architecture that will fix everything
  • system will eventually become out dated…

The solution here is very close to cleaning out your junk drawer.

  • know what belongs in your junk drawer and what does not
  • if the idea of what goes in your junk drawer expands, don’t get a bigger drawer, put those new things in a new drawer
  • clean your junk drawer(s) regularly
  • always have a spare drawer for things that might eventually go into one of your drawers or might become their own drawer

What does a junk drawer and software have in common?

Well software is full of features (junk) that can be classified in to solving domain specific problems. For example: I have a junk drawer divided into my camera stuff and my USB gadgets. Any computer system solves a certain set of problems similar to being either a “USB gadget”, or “camera stuff”.

But what happens when I get start accumulating office supplies? Well I could create a third compartment in the drawer, or I could put them temporarily in either the USB part of my junk drawer or the camera part of my junk drawer.

This is very similar to when you get a new classification of problem shoved into your current system. You could reuse an existing drawer, or create a new compartment within the current drawer taking space/resources from the camera or USB compartments. This process could continue with cables, spare DVDs, and so on, but where does it end?

In comes the spare drawer.

Now in the case of our clutter/entropy/drawer rot problem, everything could be solved by always keeping a spare drawer. Now eventually you might accumulate so much junk your entire desk is nothing but drawers, but at least when it comes to refactoring and keeping the drawers you want, you can eliminate, move, delete, etc all without effecting your “primary” junk drawer.

How do you create a spare drawer with software?

Drawer Architecture is a new term I’ll create today. It’s an architecture similar to service oriented architecture (SOA) and enterprise service bus (ESB), but everything is exposed as a restful web service, all database create/read/update/delete transactions, all business objects are exposed, the architecture at it’s core is a fully exposed web api and it’s exposed via a web based dynamic language like, Groovy, Python, Ruby, or PHP.

Stay tuned for my next post… Creating A Drawer Based Architecture.

The Corporate IT Silver Bullet Illusion

I was reading last night about how corporations get themselves into messes. Each IT generation (5 years) it seems has a silver bullet that’s going to nail down a system and make it easier to maintain enforce standards.

The current silver bullet is SOA (Service Oriented Architecture). But in 5 years what will happen is that all of the problems created by multiple databases and links between systems will overwhelm an IT departments’ ability to maintain and programmers to code. In 5 years they won’t have a single system that’s spaghetti they have multiple systems which are spaghetti complicated by the fact that you have spaghetti linking them.

I have often marveled in that change is rarely incorporated into a Corporate IT strategy. It’s either because it’s too risky/difficult to mange/define or rather than appear uncertain, which is the way it really is, managers will put a line in the sand and say this is the way it is.

So how do you fix it? How do you pick a corporate IT strategy? How do you create a system of technology and people that entropy (state of disorder) does not increase over time? You can’t, well you can’t without doing some fundamental things and spending some additional time managing the change.

  1. Use an agile or similar process that involves technology (architecture/creative/development) and the business.
  2. Use a technology platform that enables development not hinders it. A developer should not have to fight with a technology to do something.
  3. Create and Enforce DRY (Don’t Repeat Yourself) coding practices.
  4. Enforce mandatory testing and code review.
  5. Publish and get business buy-in of the development process, release cycle, and testing review requirements.
  6. Embrace and Invest in DSLs (Domain Specific Languages)

On the technology/language front, many IT managers and directors want to “standardize� on a language or pick a “framework� that will be the best fit for their environment and frankly will not get them fired if they make a bad choice. But we are coming to a point where the underlying language will not matter as DSLs begin to be used on top of traditional languages for most day to day activities and application programming. The benefit of DSLs is they will change little as the language/frameworks become obsolete and they will grow automatically as the business changes.

What is a DSL? A DSL is a Domain Specific Language a programming language specific to a domain of knowledge or business process. You can imagine a stack of programming languages like this:

  • Domain Specific Language (SQL, CSS, make, ant, regular expressions)
  • Dynamic Languages (PHP, Ruby, Python, Groovy, Perl)
  • VM Languages (Java, .Net CLR)
  • Static Languages (C, C++)
  • Assembly

In conclusion there is no Silver Bullet other than embracing the change that will happen, and creating systems, and assets that enable that change.