In his keynote for Tech.Ed 2008 in the US Bill Gates made a passing comment that chips aren’t going to be getting any faster any more. Moore’s Law is still working, but rather than processing power increasing linearly as it has until recently, chips will be adding cores instead. There are complex engineering reasons behind this that I don’t really understand but I do understand the implication of this on software development.
These implications are significant and ground-shifting for development, and therefore for architecture. In the past it has been possible to just write code and rely on computers to run that code faster as they get faster. Application not fast enough? Just run it on a faster machine.
Now things are significantly different. Designing applications that run efficiently in a multi-threaded, multi-CPU environment is non-trivial. What may be the most difficult aspect of all for many people though is that it is now necessary to think about how code is architected and written at a lower level. This is a big change for today’s developers who have not really had to be concerned with that in the past. Ironically, those of of that grew up with very slow computers may be the best placed to write code on newer machines as we know how to think about how code runs at the code level.
I believe that there is a link between this trend and the changes in user interface design that I talked about in Part 1 of this series. After all, HTML is not really going to make use of multi-threading is it? Applications that are developed intelligently to make the most use of client capabilities are going to be the best positioned to make use of parallel processing.
Of course Architects and Developers that are working on server applications will be impacted by this trend as well.
I encourage all Developers and Architects to think about design
and development in a parallel-processing environment and how the changes needed to do this fundamentally changes the way we build applications. This means being careful about the design and development of code within classes and components, not just between components.
Update: Note the changes planned for Windows 7 to support this requirement. Posted in Mary-Jo Foley’s blog: http://blogs.zdnet.com/microsoft/?p=1612
HTML is an excellent technology, and I truly raise my hat to Sir Tim Berners-Lee for inventing it. My suggestion is that by now HTML is no longer suitable as either an application development platform or is optimal an information delivery method in some cases. I’d like to present this theory as the first Architecture Big Bet.
You probably know my views on that I have been talking for some time now about the fact that desktop applications are better for internal applications that are used by users for a significant period of time. Well, the information that I have been posting here and talking about in presentations when I can has been aimed at awakening people to the options and opportunities and while technology has supported the message the widespread adoption has not been. I’ve been yelling into the ether hoping that people would hear and understand. Some have.
A number of factors are aligning to drive significant change in this area though. These are:
- Greater amounts of bandwidth;
- A focus on design thanks to Apple, Vista, mobile phones and other devices, and increasing consumerism;
- Improvements in processing power and graphical capabilities of machines and operating systems; and
- Availability of Silverlight.
I talk about Silverlight because Flash has not been able to achieve the same mindshare as Silverlight has even though it has been technically capable for some years. Also, I see Silverlight as a technology this is driving this trend.
The reason that Microsoft has achieved this state with Silverlight now, and that it will be the killer for user interfaces for all applications, is that:
- It has been developed it from a data-driven application perspective;
- That the interface between design and development is so smooth; and
- It benefits from being the next generation.
Flash was never able to move beyond advertising because it was just that little bit too hard to do things other than graphical work in it.
I see that the future web applications will be increasingly developed with a rich UI such as Silverlight rather than HTML, and in preference to AJAX. This is great, because as well as the driving factors listed above we should realise that coding in script, AJAX, HTML or whatever combination of the above we use is just simply too hard, too expensive and too hard to maintain (even with tool support).
I think that this will be the case for both intranet and Internet content.
This shift obviously results in different architecture models, with greater capabilities on the client, and a greater focus on user interface design than has been the case in the past. It brings with it a focus on entirely different UI design approaches where it is no longer necessary to make applications look like Office (see earlier posts).
So, I suggest that:
- Developers learn Silverlight;
- Architects understand what this means and build processes for design and development accordingly;
- Organisations look to employ designers; and
- Architects, Developers, BA’s and UI designers understand the new UI design paradigms needed.
What do you think?
As an Architect I concentrate less on detail these days and more on fluffy bits, so I get to spend time looking at things that are coming down the pipe and trends and changes in the future. I'm aware that many other Architects are focused differently. There might therefore be some value from me sharing some of the areas that I see changes happening in. In fact, I am finding this whole area extremely exciting at the moment (in a very geeky kind of way).
I have looked at a lot of changes that have occurred over the time in a very cynical way as bring more evolutionary, repackaging of existing technologies or cyclical than anything. Examples of these kinds of changes are AJAX (I did that in the 90's with IE5 - so last century), SOA (just good architectural design on interfaces, and interfaces are nothing new), and Agile (working together on development is something that all good Architects have done forever anyway and now that real standards and management have been added to the common view of Agile it makes sense).
Real changes that I have watched with excitement over the time have been: HTML, XML (when XML first appeared in the 90's I thought it would change the face of IT, which it has), Web Services (because the bar was finally lowered for cross-platform and cross-technology communications).
Now, I am really excited about the changes that are brewing or appearing. There are, as far as I can see, a few big things with XML-like ramifications that are either here but haven't really been noticed or are quietly evolving just over the horizon, that will reshape the industry. Over the next few days I'm going to talk to introduce them here, along with why I think they'll be big. I encourage the very quiet readers of this blog to then join in for a change and discuss.
Technorati Tags: Architecture
So Tech.Ed is over for another year. No matter what I might be doing and where I might be heading I still have a very close affinity with technology (I'm still very much a geek at heart, and even my mug says so!) and so as much as Tech.Ed is busy and tiring for a speaker there is still some sadness when it is over.
I think Tech.Ed was a success overall and I was very happy to see that my session was well received even though (or perhaps even because) it was not a deeply technical session. I'm actually rating quite well at the moment and there has been lots of positive feedback, despite the fact that, umm, apparently I say ummm too much. Oh, and I was too serious. Right on both counts. More rehearsing needed next time. For those of you that went but haven't filled in your feedback yet please login to Commnet and do so. The feedback does help enormously.
I have attached the slides to this post. If you would like the presentation given to your organisation and you are located in Australia please register an interest in this through Object's Web Site and I'll be happy to come and present in person.
I'm back at Tech.Ed Australia this year, so come see me:
ARC204 Career Development for Architects
Wednesday, 3-9-2008 14:15 - 15:30, Parkside Auditorium
The top tier of the career pyramid in the development area belongs to Architects and most Developers are aiming for that target. There is, however, little concrete information available to help people chart that course. This session will provide a map of how to chart that course in meaningful, clear and achievable steps. Kevin will leaverage from his 23 years industry experience, 15 years architecture experience and experience leading large teams of Developers and Architects to outline technical, soft, and other skills needed. He will also explain the ideal Architect profile (which is different from what most Developers think) and will cover the difficult topic of how Architects should prepare themselves for the steps after being an Architect.
I'll be around for the whole conference. Object Consulting
, my new employer (more about that soon) will have a stand there, so I'll be easy to find.
You'd think that if I was going to start posting again then I would start by talking about what makes a good Architect or something given my last post, but I want to start by listing out some thoughts that I've had about user interfaces,
The current and next big thing in architecture is the user interface. This has been stated for some time now and anyone can see from Web 2.0 and AJAX that there is a shift towards more interactive and friendly UI's. I'd like to go one step better though and put out there that the major competition to come between organisations for customers in the future will be in the UI space. And it won't just be between who has the friendliest online banking application. Rather, it will be between who provides the funkiest, smartest application that integrates best into the customers' lifestyles. This won't be a simple matter of creating the best web site or mobile phone application either. In an ealier post I suggested that Windows client applications provided advantages from various perspectives (architecture, development and end-user) over Web applications. My thinking has evolved again from there now.
I'm suggesting that the up and coming savvy consumers of today are using a wider and wider range of technologies, are understanding the capabilities and uses of these technologies and understand where they fit into their lives and when and for what they would like to use them for. Add to this a range of technologies that are just around the corner in terms of wide-spread adoption and today's Architect should be looking much, much more broadly than just a Web UI in designing applications.
. Personally I find the concept of shopping in a city that looks like a city with shops that look like shops while being at home and online to be quite fascenaticing. I feel that it holds some of the keys to the future. Universities holding courses online and companies holding meetings in Second Life is just the start. Look to some of the real world organisations like Australia's ABC that are extending their real-world presence to Second Life in ways that they Web just can't allow. While some of the security and business-model issues need to be solved there is a lot of promise there and Architects would well be advised to get their minds around the concepts.
. I was lucky enough to use Surface myself earlier in 2007 and I can say that it does work just like the videos show. It is, to me, the single biggest advance in technology in an awfully long time. It represents a completely new way of interacting with people and objects and there are a huge variety of applications where surface could be applicable. It is a viable application development platform and Architects should examine it and understand it even if just for its pure technology factor.
. Another completely innovative technology - sort of Second Life on the web with a digital camera. Yes the demos are very cute and the technology is very cool, if a little hard to explain but I can see some wonderful opportunities with Phtotsynth from a business UI perspective. The ability to navigate and select objects in a 3D world that can be readily created without serious programming or modelling (very nearly by an end-user even) could provide some powerful UI options for online stores, builders, car retailers etc.
Game Consoles. Yes, Microsoft is now doing well with the 360 but if you thought the battle for the game console market is just about units and games, even if games are now higher-grossing than movies, then I would suggest that you look more closely. The games console is no longer a games console - it is an entertainment hub and as such I am keeping a careful eye on the 360 in particular as Live becomes more powerful and the line between Live and the Web and the 360 and the PC becomes more and more blurred. This might not mean the 360 surfing the web though, but I would not be surpised to see people shopping online for general products or doing onine banking throught the ubiquitous games consoles in the near future.
Media Center et al. Vista brings Media Center to the masses and as the platform powers up we'll see it and products like it start to change the face of home entertainment devices beyond the enthusiasts that currently use it. Accessing content and applications from Media Center will become a perferable way of performing common tasks for home users and they won't want to use the Web.
So, as you can see this is only a short list of new UI paradigms that are just around the corner or are ready for development now. I would suggest that as Architects and Developers we should be considering these, and other technologies that I haven't listed, when designing applications so that the best outcome is always achieved.
Well, I'm surpised to see that at least a couple of people are still reading this despite the fact that I haven't updated this in, like, forever...
Since the last time I've updated this page I have been very busy with life and with a new role at work that has taken much more than its fair share of time. I now work as a 'Delivery Manager' for Infosys Australia. This means that I'm responsible for things like people, project governance and a whole pile of things that aren't related to Architecture. It's also lead me to question the relevance of bing an MVP for Architecture and what help I can be to other Architects and developers.
I decided in the end though that I can be a lot of help to people. You see, while I'm not exactly an Architect myself anymore I do manage about 60 Architects and 60 Developers and I do oversee a number of projects and consulting assignments that these Architects and Developers are undertaking across a range of technologies. This gives me great insight into what makes a great Architect, how Architects can succeed and achieve, what really works from an architecture perspective, and what works from a project or methodology perspective.
So, you can expect to hear more from me in future about these things and other things that interest, without giving away anything about my employer or our customers of course!
All the best, Merry Christmas and a Happy New Year!
...for ASWEC 2007. I'm the Industry Track Chair for the Australian Software Engineering Conference to be held just after Easter next year. So, its my job to put together a great program of presentations from the Australian software industry on the wonderful innovations that are being achieved in the realms of design, architecture, testing, methodology, MDA, OO, agents, and so on. I'l looking for both papers and assistance in reviewing papers. If the latter sounds like you, let me know. If you have something interesting to say, start to get your stuff together - submissions will open soon.
OK, so now you know my feelings about the way that some organisations look at implementing COTS solutions. Now, let me fill you in on another one of my pet architectural issues: the use of web broswers as a UI for applications.
I recall the history of the IT industry through the 90's well. There were three main factors at work - the growth of PC, the growth of Windows and the growth of everyone against Microsoft. Three periods existed, at least as far as client development was concerned:
In the early 90's most applications were accessed from green-screen terminals or terminal emulators (and this is still the case today for a lot of applications).
In the early to mid-90's the increasing popularity of the PC and Windows drove the use of the PC as a client, for both standalone and networked applications. Enter client-server computing, and all the problems that went with it for the brave souls that tried it. From a Microsoft architecture perspective client server was characterised, generally, by Visual Basic (or C++ for the hard-core) client applications with ActiveX controls and DLL accessed through COM on the client. The server would host more Visual Basic or C++ code using MTS. Communications between the client and server generally utilised DCOM.
In the late 90's people found ways to make use of the web browser, which had grown in use from the mid-90's, as a platform for hosting application user interfaces, driven by the issues with client-server (outlined below), the increase in the use of the Internet and a desire by some quarters to move away from the Microsoft platform.
Whatever the technical model used for the development of client-server applications a number of common problems existed:
Issues with deployment from a remote installation, remote management and bandwidth perspective;
Issues with versioning and conflicts with shared components (DLL-hell);
Issues with the use of DCOM through firewalls given its less than friendly use of ports; and
Issues with the performance of DCOM on the network.
Now, all of the above are good reasons for finding an alternative model, and in the 90's the browser was the chosen model because it provided some form of solution for each of the above issues. I, like a lot of Architects at the time, argued for why we should go from the more user-friendly client-server model to the more IT-friendly browser model and then set about building browser-based applications with CGI and ASP. The issue is that while the browser solves deployment problems for applications, from three important perspectives the browser is a huge trade-off:
From an end-user perspective browser applications are slow and screen refreshes are painful. Integration with Windows and with other applications is generally limited.
From an IT perspective browser applications are very expensive and time consuming to both develop and maintain due to the amount of code that is needed in each page to simply display and manage data.
The challenge of the above issues, of course, is that as more end user functionality that is delivered more code and therefore complexity is required. It is almost impossible to achieve a viable trade-off between usability, requirements, capability and the amount of code and complexity.
Logic would suggest that once the above issues with client-server had been solved we would all swap back to that model because it would be so much better for the end users, right? Well, for some reason this has not been the case. Most IT departments (and most architects) simply make a decision to use a browser model simply by not thinking about what other options might be available.
There are a number of technologies available today that have been available for some time that allow the development of user interfaces for applications that solve both the majority of problems with the use of browsers and at the same time provide answers for the problems that drove development to browsers in the first place.
These technologies include:
Each of the above are different in their approach and capabilities but each does offer:
Some form of smart deployment approach that avoids conflicts in its architectural design;
Some form of security mechanism to protect both the user and data;
A development model that makes UI development much faster and easier than browser development; and
Faster, friendlier and more integrated user experience than browsers.
This is an area that interests me greatly so I will be posting more in the near future. For the moment though, let me provide the following architectural principle:
All applications that are used by an end user for more than an hour per day (this includes all line of business applications) should be developed as some form of rich client. The form of client development technology used is dependent on a number of factors that I'll cover in a later posting. Browser development should be limited to occasional use applications, such as online retail banking, airline reservations, leave requests and so on.
The article that I wrote for the Microsoft Architecture Journal is now available. I hope you enjoy it. I'm very proud if it - a lot of work went into it, and I love the way it looks now it is completed. Please let me know what you think.
Feel free to email me if you have any questions or want additional information.
Please note that the views expressed in this post, along with the rest of my blog, are my own and do not reflect the views of my employer
Anna's article on the issues being faced by the organisation she has been working with where the directive is to buy, not build, but where the buy decision is clearly not right. There are a couple of principles that either organisations at a board level or IT Departments at an Enterprise Architecture level are applying that I fundamentally disagree with, and the principle of 'Buy, not Build' is one of the worst.
A solid architectural principle is to buy before reuse, and to reuse before build. This principle enshrines the concept of reuse and avoids building code where a more cost effective option exists. It is a core principle that I always use in architectural design.
There seems to be such a push towards the use of COTS products - not in a buy, reuse, build metaphor, but in a buy only metaphor, as Anna outlined in her article. This is wrong on so many levels, and yet is being implemented in a number of major Australian firms at the moment, and I have no doubt is being replicated across the globe.
COTS products offer a quick path when, and only when, the following are true:
The product has a very close fit for your requirements; and
The product can easy be configured to meet the remaining requirements; or
Your processes can be easily configured to meet the product.
In some rare cases it may be possible to extend the COTS product through a separate, but linked, system. Anything else, such as complex customisation of the COTS system to allow it to meet the requirements should not be undertaken as it will make future upgrades of the COTS product near to impossible. This results in the worst of both worlds and is far worse than building the system in the first place.
The other option that I commonly hear today is that the organisation is so set on a COTS product that they decide to change their business to suit the product. Now, I'm an Architect, not a COO, but I really struggle to see the sense in this. It is simply unworkable on a number of levels:
The cost of changing business processes is generally greater than the cost of developing software;
What may be an optimal business process for a COTS product may be common for an industry but is highly unlikely to suit the complexities of each organisation;
There is little or no room left to change business processes either because they may be sub-optimal or because the business or market conditions change.
So what is the alternative? Well, buy-reuse, build is the alternative.
When I think of buy and reuse I think of components, not monolithic systems. In some case a large system may be a good fit for common and simple processes, but a better option is to buy components and integrate them in an intelligent manner using an integration layer. SAP and Oracle understand this architecture and are componentising their systems to an increasing degree in response. This is not to say that I don't advocate the implementation of a large COTS system, but only where the system is a good fit for the organisation.
Now, the other thing that most organisations, and even many Architects, fail to take into account, is that the cost of building software is dramatically falling - especially on the .NET platform. Changes to the language, the IDE and advancements such as domain specific modelling languages and MDA are resulting in the need to build far less code (by around 50%) than even a couple of years ago. The use of workflow tools in the architecture, such as Windows Workflow Foundation or BizTalk Server, can result in a system that is flexible to business change.
Given the rapidly degreasing cost of development, matched with the ability to closely meet requirements, I would suggest that a build option is well and truly worth considering, rather than blanket C-level decisions to implement COTS systems without at least assessing the options, relative advantages and costs.
In fact, given that I've been in the industry for quite a while now and have seen fads come and go I am sure that this leaning towards blanket COTS implementations is a fad and those organisations that go down the fad route wil be reversing the decisions at a far greater expense in the future.
My wife and I were lucky enough to attend THE Microsoft Event of the Year on the weekend, and it wasn't TechEd. Yes, that's right - it was the XBOX 360 Waterballoon Challenge. We had an awsome time, and somehow managed to stay mysteriously dry, even though we were in the thick of it all, looking for trouble. Odd.
Not sure that either of us managed to hit a single person from the other side (we were on the Green Team) and I'm pretty sure that every water balloon managed to get either (a) someone from our team or (b) someone that wasn't even in the playing field, like those pikers that sat outside to watch rather than joining in. If you look at the pics of the big XBOX 360 logo I'm sure you can see us - right on the top right hand point of the first X....
It was a blast. Got our shiny new copies of PGR3 and Kameo. Now all I need is a 360.
Well, ASWEC has just finished. This was the Australian Software Engineering Conference. You most likely won't have heard of it as it is pretty small, but I thoroughly enjoyed it. It has papers from academia and from industry on software engineering and is vendor-independent. The quality of presentations was very impressive, and they were all engineering, rather than product focussed. I was lucky enough to receive an award for 'Best Industry Experience Award' - in other words, best presentation from the 14 presented by people from organisations as opposed to those from universities. The paper was "Large Scale Integration Design and Management". Yay. I can recommend that anyone interested in architecture should attend the next one - after easter 2007.
Thanks to Anna too for her kind words...
Well, it came from a conversation at the MVP Summit in Redmond Sept 2005. The comment was made that more information is needed for Architects to show how technologies should and shouldn't be used. This differs from the common marketing-focussed documentation that is generally available. The need is for this kind of 'Yes, but' documentation then, but this kind of information is best provided by MVP's and other 'external' people. That therefore is one of the aims of the Blog - to provide the 'Yes, but' documentation.
Up and running at last. Thanks to Susan for the wonderful service.
Hi to Lee, Jayanne and Joshua. Love you guys. Thanks for everything.
More Posts « Previous page